10.2 Creating & Launching an Outbound EIB

What an outbound EIB does

An outbound EIB extracts data from Workday and delivers it somewhere. For a platform administrator it is the standard answer to "the vendor needs a file of X every Monday" when no connector exists for that vendor.

Get, Transform, Deliver

Step 1 - build and enable the report

The report is the integration. Everything the file contains is decided here.

1. Build the report as Advanced. Only Advanced reports can be enabled as a web service. If an existing Simple report is close, copy it into an Advanced report rather than trying to convert it.
2. Get the columns and filters exactly right, in the order the destination expects. Column order in the report drives field order in the output.
3. Enable the report as a web service from its Related Actions. This produces Reporting as a Service (RaaS).

RaaS requires no web service knowledge. A custom report enabled as a web service does not require a user to select a web service operation or write a request. That is precisely what makes report-driven outbound EIBs accessible to administrators.

Step 2 - create the EIB and point it at the report

Run Create EIB and set the direction to Outbound. In the Get configuration, select the custom report enabled as a web service as the data source, and supply values for any prompts the report defines.

Prompt values matter at schedule time. A report with a date prompt needs a value each run. Use a calculated field with Determine Value at Runtime - the pattern from sections 8.1 and 8.3 - so a rolling window resolves automatically instead of requiring a monthly edit.

Step 3 - configure the transformation

If the destination needs a different shape from the report's native output, configure a transformation. If the destination accepts the report output as delivered - CSV or XML - none is needed. A basic outbound EIB commonly has no transformation at all, which is a legitimate design and not an omission.

When the requirement genuinely exceeds what an EIB transformation can express - multiple output files, a complex non-XML layout, custom error messaging - that is the signal to move to Document Transformation on a connector, or to Workday Studio. Recognizing that boundary is part of the objective.

Step 4 - configure delivery

Delivery configuration carries the endpoint address and its credentials. Two operational points: credentials expire, and a rotated SFTP key is a frequent cause of a long-working integration suddenly failing delivery while the data extract still succeeds; and integration output can be encrypted, since Workday integrations support encryption.

Step 5 - launch and schedule

Launch manually first and inspect the output before scheduling anything.

Then schedule it. Scheduled integrations run as an Integration System User, so the ISU and its ISSG must be configured as in section 9.3 - and the ISSG needs Get on the domains securing the report's data source and report fields.

Security for an outbound EIB

An outbound EIB reads, so it needs Get. Most outbound integrations need Get only, so Put should not be granted unless the integration genuinely writes back.

The account needs access to exactly what a person running the report would need:

• The domain securing the report's data source
• The domains securing each report field - including fields used only in filters
• The domain securing the data source filter, if one is applied

This is the single most useful troubleshooting fact in this section. An outbound EIB that fails on a field the output does not contain is failing on a filter field. It is the same root cause as the reporting error in section 8.4, arriving through a different door.

There is a second, quieter failure mode. If the ISSG is constrained, the report returns only the instances that account can see. The integration succeeds, the file is delivered, and it is incomplete - with no error anywhere. When a vendor reports missing records and Workday reports success, compare the row count the ISU produces against the row count a human with wider access produces.

Testing an outbound EIB

1. Run the report interactively and confirm the rows and columns are exactly right.
2. Launch the EIB manually and retrieve the output.
3. Compare the file against the report output - column order, formats, headers, delimiters, and encoding.
4. Confirm the row count matches what a fully privileged user sees, to catch a constrained ISSG.
5. Test delivery to a test destination before pointing at the vendor.
6. Schedule it, then verify the first scheduled run separately - it is the first execution that uses the ISU rather than your own account, and it is where an unactivated policy change or a missing Get permission surfaces.

Exam framing: questions about an outbound EIB producing wrong or incomplete data almost always resolve to the report or to the ISU's security scope, not to the EIB configuration. The EIB is plumbing; the report and the security are the substance.