Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2026-04-03
Integration Business Process Guidelines

Integration Business Process Guidelines

Overview

An Integration Business Process is a configurable workflow that orchestrates the tasks associated with running an integration for exchanging data between Workday and external endpoints. It uses the
Integration Process Event
 business process type, which allows for more complex processing than a simple integration launch. See Concept: Integration Business Processes.
These are the sections in this topic:
  • Subprocesses
  • Prerequisites
  • Process Initiators
  • Limitations
  • Common Business Process Workflows
  • Workflow Steps
  • Integration
  • Notifications
  • Issues and Solutions

Subprocesses

You can embed an integration within another business process by adding an Integration step to that business process's definition. When the parent business process reaches that step, it launches the specified Integration Process Event as a sub business process.

Process Initiators

An Integration Business Process can be initiated in several ways:
  • Manually
    A user with appropriate permissions can launch the integration directly from the
    View Integration System
     report or by using the
    Launch/Schedule Integration
     task.
  • Scheduled
    You can schedule the integration to run at a specific time or on a recurring basis from the
    Launch/Schedule Integration
     task.
  • As a sub business process
    The Integration Business Process can be initiated from a step within another Workday business process (Example: running an E-Verify integration after the
    Complete Form I-9
     business process).

Limitations

While the Integration Business Process framework is flexible, the underlying integration technology has specific limitations.
  • Organization for an integration system from a web service launch
    When launching an integration via the
    Launch_Integration
     or
    Launch_EIB
     web service operations, you can't specify a particular organization-specific version of the business process. The top-level (default) definition for that integration system will be used. See
    Organizations and Integration Business Processes
     in Concept: Integration Business Processes.
  • File size limit for document retrieval
    Inbound files have a limit of 1 GB for XML and 300MB for XLSX. See Reference: Integrations and Web Service Limits.

Common Business Process Workflows

Path 1: Default Integration Workflow
By default, the
Integration Process Event
 consists of two fundamental steps:
A: Initiation
>
 B: Service (Fire Integration)
The
Service (Fire Integration)
 step executes the integration system itself. For an outbound integration, it generates the output file. For an inbound integration, it loads data into Workday.
Path 2: Outbound Integration with Approval
This workflow is common when you need a user to review data before it's sent out of Workday.
A: Initiation
>
 B: Approval
>
 C: Service (Fire Integration)
>
 D: Service: Document Delivery
Once approved, the
Service (Fire Integration)
 step runs and extracts the data from Workday, generating the output file.
The
Service: Document Delivery
 step delivers the generated file to the external endpoint, such as an SFTP server.
Path 3: Inbound Integration Workflow
This workflow is a standard workflow for bringing data into Workday from an external source.
A: Initiation
>
 B: Service: Document Retrieval
>
 C: Service (Fire Integration)
The
Service: Document Retrieval
 step retrieves a file from an external source (like an FTP server) or routes a task to a user to manually upload a file.
The
Service: Fire Integration
 step executes the integration, taking the retrieved file and loading the data into Workday.
Path 4: Chained Integration Workflow
This pattern is useful when one integration's output is the input for another.
A: Initiation
>
 B: Integration
>
 C: Integration
The first
Integration
 step triggers the first integration system (Example: an EIB or a Studio integration) to run and produce an output file.
The second
Integration
 step triggers a second integration system, which consumes the output file from the first integration.

Workflow Steps

Initiation
Order
A (First Step)
Performed by
The user or system that launches the integration. This can be an Integration System User (ISU) for scheduled or system-triggered events, or an interactive user for manual launches.
Security Domain by role
ISU or Integration administrator who launches the integration:
Modify / Put
 access to
Integration Build
,
Integration Configure
,
Integration Debug
,
Integration Event
.
Best Practice
The
Initiation
 step is a mandatory first step for all business processes. It cannot be removed. It serves as the entry point and audit record for the process starting.
Example
An HR Administrator navigates to the
Launch/Schedule Integration
 task and clicks "
OK
" to run a new hire export to an external benefits vendor. This action completes the
Initiation
 step and begins the business process workflow.
Step Types
Here are the common step types you can add to an Integration Business Process.
Approval
Order
Can be placed anywhere after the
Initiation
 step. For example, you could place it after a
Fire Integration
 step but before a
Document Delivery
 step.
Performed by
A specified security group (e.g., HR Partner, Compensation Administrator, Manager).
Security Domains
ISU, Integration administrator, or Business Process administrator:
Modify / Put
 access to
Integration Event
.
Specify
You must specify the security group(s) responsible for the approval.
Condition Rule
  • Use Case: Require a manager to review and approve a file containing employee bonus data before it is delivered to the payroll vendor.
  • Best Practice: Use condition rules to trigger approvals only when necessary. For example, you could create a rule that skips the approval step if the total bonus amount is below a certain threshold.
  • Example: A condition rule is configured on the approval step to check if the "Total Bonus Amount" field in the integration output is greater than $50,000. If it is, the step is routed to the
    Compensation Administrator
     security group for approval. Otherwise, the step is skipped.
Step Type Use Cases, Best Practices, and Example:
  • Use Case: Ensure data accuracy for sensitive outbound integrations like payroll or stock grants.
  • Best Practice: Assign approvals to a role-based security group rather than a specific named user to avoid process delays due to employee absence.
  • Example: Before delivering a file of executive compensation changes to an external system, an
    Approval
     step is routed to the
    Executive Compensation Admin
     security group to validate the data.
Service
Order
Can be placed anywhere after
Initiation
. The order is critical. For an inbound integration,
Document Retrieval
 must come before
Fire Integration
. For an outbound,
Fire Integration
 must come before
Document Delivery
.
Performed by
Integration System User (ISU).
Security Domains by role
ISU:
Modify / Put
 access to
Integration Build
,
Integration Configure
.
Specify
You must specify the service to be executed:
Document Retrieval
,
Document Delivery
, or
Fire Integration
.
Condition Rule
  • Use Case: For an integration that runs daily, you might only need to retrieve a file on the first day of the week.
  • Best Practice: Use condition rules on
    Document Delivery
     steps to prevent sending empty files. You can create a rule that checks if the integration event's record count is greater than zero.
  • Example: A condition rule on a
    Document Delivery
     step checks a calculated field that counts the number of records processed by the
    Fire Integration
     step. The delivery step only runs if the count is greater than 0, preventing the system from sending a blank file to the vendor.
Step Type Considerations
  • Document Retrieval: Used in inbound integrations to pull a file from an external source (like an SFTP server).
  • Fire Integration: This is the core step that executes the main integration system, either generating an output file (outbound) or loading data into Workday (inbound).
  • Document Delivery: Used in outbound integrations to send a generated file to an external destination (like an SFTP server or web service endpoint).
To Do
Order
Can be placed anywhere in the process where a manual action or instruction is needed.
Performed By
A specified security group or user.
Security Domains
ISU, Integration administrator, or Business Process administrator:
Modify / Put
 access to
Integration Event
.
Condition Rule
Useful for triggering manual intervention only when needed. For example, a rule could check if the integration event status is "
Completed with Warnings
," triggering a
To Do
 for an administrator to review the warnings.
Step Type Use Cases, Best Practices, and Examples
  • Use Case: Notifying an administrator to perform a manual task outside of Workday or to verify data within Workday after a process step.
  • Best Practice: Make the instructions in the
    To Do
     step clear and actionable. Include links to relevant reports or tasks if possible.
  • Example: An inbound EIB loads new contingent workers. A
    To Do
     step is configured to trigger after the
    Service - Fire Integration
     step. It is assigned to the
    HRIS Analyst
     group with the instruction: "Contingent workers have been loaded. Please run the 'Audit New Hires' report to verify their data and complete any missing localizations."

Integration

This step type allows you to launch another, separate integration system from within the current business process. This is how you chain integrations together.
Order
Can be placed anywhere after the
Initiation
 step.
Performed by
Integration System User (ISU).
Specify
You must select the Integration System to be launched as a sub process.
Condition Rules with Use Cases, Best Practices, and Example
Use Case: After a main outbound integration runs, you want to run a second integration to archive the generated file to a long-term storage location, but only if the first integration was successful.
Use a condition rule to check the status of a previous step (
Fire Integration
) to ensure it completed successfully before launching a subsequent integration that depends on its output.
Example: An
Integration
 step is configured to launch an "Archive Integration". A condition rule on this step checks the status of the preceding
Fire Integration
 step. The archive integration only runs if the status of the preceding step is "
Completed
".
Use Case: You want to retrieve a file without launching an integration, or launch an integration without delivering a file.
Use a condition rule that always evaluates to false. Example: “1=2” on the step that should be skipped.
Step Type Use Cases
  • Use Case (Data enrichment): An initial integration extracts basic employee data. A second
    Integration
     step calls a different integration that takes the initial output, adds data from another source (like a custom report), and produces a final, enriched file.
  • Use Case (Process orchestration): After an inbound EIB loads new hires, an
    Integration
     step could trigger an outbound integration to provision accounts for those new hires in an external IT system.
  • Use Case (Redirecting failures): When an integration step fails, route the failed integration to specific users instead of automatically terminating the business process.
    1. Configure security groups to have
      Redirect
       permissions on the business process security policy.
    2. Use the
      Maintain Redirect
       related action on the
      Integration
       step of the business process definition.
    3. Select 1 or more redirect actions, and select 1 or more security groups to receive the redirected step.
Step Type Example
The business process starts and the first step,
Service (Fire Integration)
, runs the
PayData Extract
 integration, which generates a raw payroll data file. The next step,
Integration
, is configured to launch the
PayData Transformation
 integration. This second integration is designed to pick up the file from the first, reformat it into the vendor's required XML layout, and place the new file in the outbound holding area. The final step,
Service (Document Delivery)
, delivers the transformed XML file to the payroll vendor.

Notifications

Custom notifications are triggered by the final status of the overall integration process event. You can configure notifications on the business process definition itself (Example: on step completion or error).
Use Cases with Best Practice and Example:
  • Use Case (Success): Send an email to the Payroll team confirming that the weekly payroll interface file was successfully generated and delivered to the vendor.
  • Use Case (Error): If an integration fails, send a high-priority notification to the Integration Administration team with the event details and error messages so they can investigate immediately.
  • Best Practice: Use specific, role-based security groups (e.g.,
    Integration Administrators
    ) as recipients rather than individual users. Create clear and actionable notification messages that include key information, such as the name of the integration, the time it ran, and a link to the process monitor for details.
  • Example: An integration notification is configured to trigger when the business process status is "
    Failed
    ". It sends an email to the
    Integration Support
     security group. The email body is customized to say: "The integration
    CCB - Outbound Demographics
     has failed. Please review the Process Monitor for details. Event ID: [Event ID]".

Issues and Solutions

This section lists common issues along with their corresponding causes and solutions. For issues not listed here, we recommend searching for knowledge articles in Community. For best results:
  1. Search for the exact name of the process using double quotes. Example: "Integration Business Process".
  2. Refine the initial results by selecting these search filters:
    • Content Group
      : Articles
    • Content Type
      : Knowledge Article
  3. Use the
    Sort by
     filter to view the results by
    Relevance
    or
    Newest
    .
Issue
Cause and Solution
External endpoint doesn't receive an expected integration file.
Use the
Process Monitor
 and
Full Process Record
 reports to determine what didn’t work as expected. See
Troubleshooting Integration Process Events
 in Concept: Integration Business Processes.
Outbound file was not delivered to the external endpoint.
Cause: The business process may have failed before the
Document Delivery
 step, or the delivery step itself failed.
Solution: To view the status and error messages related to the failure:
  1. From the
    Process Monitor
     report on the
    Integration
     process type, find your integration request.
  2. On the
    View Background Process
     page, click the
    Parent Event
    , which is the integration process event.
  3. On the
    View Event
     page, the
    Subsequent Processes
     table displays the integration events for the
    Integration
     and the
    Deliver Document
     steps.
  4. Review the status and error messages for both to pinpoint the failure.
  5. Verify the endpoint credentials and address in the delivery configuration.
Inbound integration did not load any data.
Cause: The
Document Retrieval
 step may have failed to find the file, the file could be empty, or the
Fire Integration
 step failed during the data load.
Solution: Verify that the file exists at the specified external location and that the file name matches the configuration. Check the
Integration Events
 report. To view the process error messages related to file parsing or data validation, select the
Created from Trigger
 column for the integration event.
An approval step was incorrectly routed or skipped.
Cause: The condition rule on the approval step may be configured incorrectly, or the members of the specified security group may be incorrect.
Solution: Use the
View Business Process Definition
 report to review the step's condition rule logic. Use the
View Security Group
 report to verify the membership of the assigned approver group.
Integration fails with a security error.
Cause: The Integration System User (ISU) associated with the integration is missing permissions for a required security domain.
Solution: Review the error message in the
Integration Events
 details to identify the protected data or action. Access the
Domain Security Policies for Functional Area
 report to find the relevant domain and add it to the security groups assigned to the ISU.
All integrations fail to launch with the error: "There is no Default Definition for the 'Integration Process Event' Business Process Type..."
Cause: The default business process definition for
Integration Process Event
 has been inactivated, deleted, or edited incorrectly and saved with errors. All integrations rely on this definition as a base.
Solution:
  1. Run the report
    Business Process types with Default Definitions in Use
    .
  2. Filter for the
    Integration Process Event
     type to find the definition.
  3. Review the definition and ensure it is active and contains, at a minimum, an
    Initiation
     step and a
    Service (Fire Integration)
     step. Correct any errors and save.
Integration Business Process notifications are configured but are not being delivered via email.
Cause: The tenant-level notification routing rules are not set up to send integration-related notifications via email.
Solution:
  1. Access the
    Tenant Setup - Notifications
     task.
  2. In the Notification Sub-Type settings for
    System
    , find the
    Integrations
     row.
  3. Set the Notification Routing Rule to
    Email / Immediately
     or another appropriate email-enabled rule.
A chained integration (launched from an
Integration
 step) fails, causing the entire parent business process to terminate.
Cause: This is the designed and expected behavior in Workday. The failure of any step in a business process, including an
Integration
 step, will halt the process by default to prevent further errors.
Solution: This is not an error to be "fixed" but a behavior to be managed.
  1. Ensure the child integration has robust error handling and its own specific notifications.
  2. Review the parent process to see if the child integration is truly critical. If not, it may need to be decoupled and run as a separate, scheduled process rather than being chained.
A Studio integration step with errors is not redirected, even if it’s configured with
Maintain Redirect
.
Cause: Currently the
Maintain Redirect
 feature only works on Studio integrations that complete with a status of "
Failed
". If a Studio integration completes with a status of "
Completed with Errors
" then this will not be considered a failure by the
Maintain Redirect
 functionality.
Solution: This is not an error to be "fixed" but a behavior to be managed. Ensure the integration has robust error handling and its own specific notifications. See Configure Redirect on Business Process Steps.