Process Automator Triggers
Use triggers to define an event in Coupa that causes the process to begin.
The below table includes Process Automator triggers, descriptions, and subsequent options:
| Field Name | Description |
|---|---|
| Launch Process on |
Select the action that triggers the process. Values can be:
|
| For processes launched on a Document Event | |
| Document | Specifies the object on which the trigger will be set. Document could be a Contract, Expense Report, Invoice, Order, Purchase Order, Purchase Order Change, Requisition, or Sourcing Event. |
| Trigger process on (required) |
The object event that starts the process evaluation using the conditions defined after the Object and Action are selected in Step 1 > Perform Action. Different documents have different triggers that can be used to start the process. See the Documents and triggers table below. |
| For processes launched on a UI button click, the following creates a button that can send a URL encoded request. | |
| Content Groups | Defines the user groups that should have access to see and use the button. Content Groups must be defined separately if you wish to limit who has access to trigger this process. |
| Button Location | Select one of the following documents - modalities:
|
| Button Name | Text (20 characters max) to be displayed as the button label |
| Button Alt Text | Alternate text that appears when cursor is hovered over the button |
| Launch URL | Once you save the process, viewing that process gives you access to the URL used to invoke it so that the process may be run and used in other contexts given proper document params. Use a console in developer tools to see how document params are passed. |
| For processes launched on Option Selected | |
| Document | Specifies the form that starts the Guided Flow. Supported options are:
|
| Option that a user selects that triggers the process. Currently, the supported option is New Supplier. This launches a Guided Form when a user is completing a Requisition Line form and needs to add a new supplier, allowing the end user to complete the Requsition Line form and New Supplier form within the same flow. | |
Documents and triggers
This table shows each document type and their supported triggers.
| Application | Document | Trigger |
|---|---|---|
| Contract Management | Contract |
|
| Platform | Forms (all form types) | Form Response Completed |
| Custom Object | Create or Edit | |
| Invoice | Invoice |
|
| Pay | Charge |
|
| CoupaPay Payment |
|
|
| Procure | Order Confirmation | On Pending Integration |
| Purchase Order |
|
|
| Purchase Order Change |
|
|
| Receipt |
|
|
| Requisition |
|
|
| Risk Assess | Risk Request |
Start New Risk Assessment |
| Sourcing | Sourcing Event |
|
| Supplier Information Management | SIM Form |
Note
See Applied trigger section for more information about this trigger. |
| Supplier Management | Supplier Insight |
Scheduled Job Evaluation |
| Travel & Expense | Expense Report |
Approved For Payment |
Purchase Order Change Triggers
This table includes more information about Purchase Order Change triggers.
|
Status/Action |
Description |
|
|
Approver Hold |
When one of the approvers puts the PO change on hold |
|
|
First Submit |
When a change is submitted for the first time (This status is not applicable when requester resubmits a PO change after rejection or withdrawal) |
|
|
Fully Approved |
When the PO change is approved by the last approver |
|
|
Payment Authorization Hold |
When the PO change doesn’t meet the PO Payment Authorization criteria (if enabled) |
|
|
Pending Approval |
When the PO change is sent to first approver in the PO change approval chain |
|
|
Rejected by an Approver |
When the PO change is rejected by any approver |
|
|
Withdrawn by a Requester |
When the PO change is withdrawn by any requester |
|
Applied trigger behavior
To avoid duplicate executions when using this trigger type, the following behavior applies:
-
When a SIM Easy Form response is applied, Process Automator checks whether the form is an external SIM form.
- If the form is an external SIM form, one of two conditions applies:
- If a Supplier initiated the form, the process executes.
- If a Supplier did not initiate the form (for example, if it was submitted as part of the supplier onboarding process), the process does not execute to prevent duplicate actions. In this case, a separate process fulfils the request. See example below for examples of each request.
- If the form is not an external SIM form, the process executes.
Processing only supplier-initiated external forms prevents duplicate processes while maintaining consistency in the onboarding process.
Example: Supplier-initiated process
The below example process executes when a Supplier submits an external SIM form.
Example: Onboarding-intiated process
The below example process executes as part of the supplier onboarding process.
