Application & Process Automation
- Getting Started
- Common Usage Scenarios
- Troubleshooting
- Using Custom IDs
- API Method Reference
-
- GetPrograms
- GetForms
- GetFormSchema
- GetProjects
- GetProjectsByNumber
- GetProjectsByData
- CreateNewProject
- GetAllProjectData - Admin only
- GetProjectData
- SetProjectData
- GetActiveAttachment
- GetAttachmentAsAdmin – Admin only
- SetProjectAttachment
- SetAttachmentMetadata
- GetAttachmentMetadata
- SubmitProject
- GetStatusList – Admin only
- GetCustomListChoices
- GetProjectStatusHistory – Admin only
- SetProjectStatus – Admin only
- GetExportProject – Admin only
- CreateMfaSessionToken
- DeleteMfaSessionToken
- SetAssignee
- SetProjectOwner
- GetInquiryThreads – Admin Only
- GetNotesInInquiryThread – Admin Only
- SetInquiryNote – Admin Only
- SetInquiryThreadStatus – Admin Only
- SetInquiryThreadExternalId – Admin Only
- SetProjectStatusReportAs – Admin only
- Code Samples
Using Custom IDs
The unique-looking IDs that PowerClerk is using to identify all objects are automatically generated per program, and make it possible to uniquely identify which object a caller is referring to, without having to worry about program administrators relabelling those objects through the UI. However, it makes the exercise of mapping esp. data fields and attachments an exercise that needs to be repeated per program (incl. if trying to test in a test environment). Custom IDs can be set by an administrator (one that has the privilege to set those) for:
- data fields
- attachments
- forms
- status
Those stay constant if moving from a sandbox to production, or from production to a test environment. They are only unique within their object type, i.e. an attachment and a data field can have the same custom ID. If a custom ID has been set, that can be used in place of the automatically generated unique ID.
What’s Next?