What Trigger Integration can and cannot start

The Trigger Integration component starts another integration in your tenant from an orchestration. The child can be a Workday-delivered packaged integration, a custom Workday Studio integration, or another orchestration built on the Workday Integration System template. EIBs are not supported (Concept: Triggering Integrations).

The component only exists in the Workday Integration System orchestration template. You can put it in the top-level workflow, error handlers, branches, loops, batch loops and suborchestrations, but not in a join loop.

What the orchestration does while the child runs

After the trigger, the parent orchestration stops. The child runs asynchronously and, when it finishes, sends a callback to Orchestrate with its status and results, and the parent resumes. The step then exposes the child's status information, its integration messages (PIMs) and any documents it attached as outputs, which is what downstream steps and error handlers read.

Retry settings on the step are narrower than they look. They retry a failure to trigger the integration, not a child that started and failed. To relaunch a failed child, route the failure through an error handler.

Who the child runs as

The Auth tab offers two choices: Default Workday API Credential or Access Token from Initiating User. Whichever you pick, the user on the step is the initiating user and needs permission to launch the child.

If the child integration system has an integration system user (ISU) in its definition, that ISU is the "run as" user. If it has none, the step's user is both the initiating and the "run as" user and needs both permissions (Reference: Trigger Integration). Setting up the account is covered in Integration system users and API clients.

Passing launch parameters and one document

On the Launch Parameters tab, connect to the tenant with Manage Connections, search for the child integration system by name and link it. Orchestration Builder imports the child's launch parameter definitions, grouped by service provider type. Give each one an expression and use Send in Launch to decide whether it goes along. Refresh Launch Parameters re-imports the definitions. If a parameter that already has an expression has been removed from the child, you are asked to exclude it or drop the expression. Linking is optional, because you can configure the step by hand.

The Document tab passes a single document. Document to Store, Document Title and Storage Expires In are required, and leaving them blank produces validation errors. Storage expires after 7 days if you set nothing, with a maximum of 1 year. For a month, the reference gives zoneddatetime.now().plusMonths(1). Tags are accepted only if they already exist in the tenant. If you leave Collection to Store Document In empty, Workday creates a collection named after the child integration system's WID.

The child sees only that one document and whatever it creates itself. It cannot read other documents the parent has produced, so a parent that needs to hand over two files must combine them first.

Why a data load is not a Trigger Integration job

Because EIBs are excluded, an orchestration cannot load a spreadsheet into Workday by triggering an EIB. Writing data from an orchestration means calling a Workday web service directly. Workday groups them by operation type: Put creates or updates data, Import loads large documents with many lines, Bulk Import processes many small documents asynchronously, and Submit uses the relevant business process (Reference: Common Workday Web Service Operation Types). The best-practices page recommends Put for small requests and single documents, Import for large requests, and Bulk Import for large batches of individual documents (Concept: Workday Web Services Best Practices).

Trigger Integration is the right tool when logic already exists as a Studio or packaged integration that you want to chain, or to run on a condition. When the job is "send these lines to Workday", call the web service from the orchestration.

Calling an Import web service from an orchestration

Send Workday API Request is the data requests component for Workday APIs, and Workday says not to use Send HTTP Request for them (Concept: Data Requests Components in Extend Apps). Workday's Supplier Invoices Inbound sample in the App Catalog shows the whole pattern. A Create Text Template step builds the Import_Supplier_Invoice_Request body with content type text/xml. Send Workday API Request then POSTs it to the relative path soap/v43.0/Resource_Management with the default Workday credential. The import itself runs asynchronously in Workday, so a second integration in the sample reads the outcome with Get_Import_Processes and, when the process has messages, Get_Import_Process_Messages.

With Send Workday API Request the SOAP envelope is yours to supply. The sample writes it into the import template by hand, and wraps the Get_Import_Processes body with the wrapSoapV11() XML member function instead (Reference: Xml Member Functions). Send Paged Workday SOAP Call works the other way: it adds the envelope itself, a body that already has one is invalid, and it is built for paginated responses you iterate over, which is how the sample reads the import messages (Reference: Send Paged Workday SOAP Call).

Two limits matter for large loads. Incoming Import web service requests can be up to 2 GB, while other incoming web service requests are capped at 500 MB (Reference: Integrations, EIB, and Web Service Limits). A single long-running call can be waited on, by turning on Enable Wait for Long Running Response in the step's Advanced Mode, for up to 6 hours for SOAP APIs (Reference: Send Workday API Request). Inside a loop, that setting makes the iterations run one after another.

Payroll input has both an Import and a Put operation for the same data, which makes it a good worked case of this choice: Loading payroll input with Orchestrate.

How to prove a Trigger Integration step worked

Open the parent's integration event and confirm the Trigger Integration step has resumed after the callback, not only launched. Then open the child's own integration event in the tenant and compare its status and messages with the step's outputs. The step hands the child's status to later steps, so the recommended pattern is to add a Branch on Conditions on that status after the step and route a failed child to an error handler, as described in Orchestrate errors. For an Import call, the proof is the import process itself: Get_Import_Processes returns its status and whether it has messages.

Sources checked