Workday Studio Store, Log, and Put Integration Message: Building Audit Trails

Workday Studio provides four distinct mechanisms for recording diagnostic data, user-facing alerts, and output files during an integration run: the Log (log) step writes technical entries to the ESB server log, PutIntegrationMessage (PIM) posts status-driving messages and document links to the integration event's Messages tab, the Cloud Log (cloud-log) buffers structured HTML, CSV, or XLSX record logs in a variable, and the Store (store) step persists files in the Workday Blobitory. Selecting the wrong logging mechanism—such as calling PutIntegrationMessage inside a record loop or dumping full XML payloads into log steps—degrades integration performance, overwrites the mediation message, or exposes confidential worker data.

Compare Studio logging and storage components

Each logging and persistence component targets a specific audience and location within the Workday tenant:

Control integration event status with PutIntegrationMessage

When you drop PutIntegrationMessage onto an assembly canvas, Studio inserts a local-out calling the vm://wcc/PutIntegrationMessage common component. Internally, PIM executes the Put_Integration_Message Workday Web Service operation.

Severity levels and event status transitions

The is.message.severity parameter on a PIM component directly controls the parent Integration Event status displayed in Integration Events and Process Monitor:

Setting is.message.severity on a PIM updates the event status in Workday, but the PIM itself does not halt or rewind the assembly. Your error handlers (send-error with Continue After Error set to rewind or recover, and the global-error-handler) control whether execution continues or aborts.

Attaching clickable object targets and details

To make integration error messages actionable for functional administrators, populate four elements in your message text: Context (which worker, invoice, or map failed), Condition (what was invalid or missing), Requirement (what Workday or the vendor expects), and Response (how to fix it).

You can also link specific Workday business objects directly to the message row on the Messages tab using these PIM parameters:

• is.message.summary: Concise headline shown in the message table (for example, 'Missing Cost Center for Worker ' + props['worker.id']).
• is.message.detail: Detailed troubleshooting text; supports rich text when is.message.detail.richtext is true (default).
• is.message.targets: A comma-separated list of object identifiers (such as Worker WIDs or Employee IDs) that render as clickable object links in the Workday UI on the View Integration Message tab.
• is.message.targets.type: The reference ID type for is.message.targets (defaults to 'WID', or set to 'Employee_ID', 'Contingent_Worker_ID', etc.).
• is.message.secured.instance.refs: Comma-separated references (is.message.secured.instance.refs.type defaults to 'WID') that restrict who can view the message based on instance-level security.

Three critical PutIntegrationMessage pitfalls

1. PIM overwrites the Mediation Message: Because PutIntegrationMessage builds a SOAP request payload for Put_Integration_Message, it replaces the current Mediation Message with its web service request and response. If downstream components still need the current XML payload, either set Clone Request = true on the PIM's Advanced tab or copy the Mediation Message into a variable (vars) before calling the PIM.
2. The 500-message ceiling: Workday caps PutIntegrationMessage calls at 500 messages per integration event. Once an integration exceeds 500 PIM calls, Workday stops displaying new text-only messages on the Messages tab and redirects them to the server log—unless the PIM attaches a document, includes is.message.targets, or escalates the event status.
3. Web service latency in loops: Because every PIM execution performs a SOAP round-trip, placing a PIM inside a splitter or record loop severely slows down large runs. Use Cloud Log inside record loops and reserve PIM for high-level summaries and error counts.

Persist deliverables and audit files with the Store step

The Store (store) step writes a mediation message or variable to the Workday document repository (the Workday Blobitory) and outputs an Atom Syndication Format (2005/Atom schema) metadata document containing the stored file's entry ID, title, size, publication timestamp, and expiration date.

Retention policies (Expires In vs Expires On)

Every stored file must carry an expiration window so old payloads do not accumulate indefinitely in the tenant repository:

• Expires In (expiresIn): Expressed in XSD duration format. The default is P7D (7 days). For example, P30D retains the document for 30 days, and P1Y3M5DT8H45M10S specifies 1 year, 3 months, 5 days, 8 hours, 45 minutes, and 10 seconds. Keep retention windows as short as your compliance and troubleshooting policy allows (typically 7 to 30 days).
• Expires On (expiresOn): Found on the Advanced tab; accepts an exact UTC timestamp in CCYY-MM-DDThh:mm:ssZ format and overrides Expires In if specified.

How to make stored files deliverable (Store + PutIntegrationMessage)

How you link a stored Blobitory file to the integration event determines whether a downstream Service - Document Delivery step on the Integration Process Event business process can transmit the file to an external SFTP or HTTP endpoint:

When using Option 2 with multiple delivery steps on your business process, populate is.document.labels (comma-separated strings) or is.document.delivery.services on the PIM so each delivery service step transmits only the files tagged for that destination.

Use Cloud Log (cloud-log) for record-level audit files

Introduced as the standard logging pattern in the Workday Studio Starter Kit (SSK), the Cloud Log (cloud-log) step gives functional users a clean, searchable audit file without firing hundreds of PutIntegrationMessage web service calls or cluttering the technical server log.

1. Add a cloud-log step inside your record-processing or error-handling mediation.
2. Configure Variable Name (variable-name, for example myCloudLogVar). Multiple cloud-log steps across different subassemblies can write to the same variable name to concatenate all entries into one unified report.
3. Choose Output File Type (output-file-type): HTML (interactive, filterable viewer), CSV, or XLSX.
4. Populate Level (debug, info, warn, error, fatal, or custom), Message, Message Details, and Reference ID (such as Employee ID). Use the Extra Columns tab (Key, Label, Value) to add structured columns like Cost Center or Error Code.
5. At the end of the assembly (and inside your global-error-handler path so logs are still saved on failure), add a Store step with Input set to variable (myCloudLogVar), Title set to Audit_Log.html, and Create Document Reference set to true.

Because cloud-log appends to a mediation context variable backed by ESB disk space and only writes to the Blobitory once at the end of the run, it leaves the Mediation Message untouched and adds negligible runtime overhead.

Keep Log (log) steps safe in production

The basic Log (log) step writes raw text to the server log (48 MB file limit, 128 KB line limit). Follow two rules for log steps in production assemblies:

• Never log the Mediation Message or unmasked variables in production: Any user with Integration Event domain permissions can download the server log and view raw SOAP or RaaS responses containing compensation or personal identifiers. Use the Workday Studio interactive debugger during development instead.
• Gate diagnostic log steps behind an Integration Attribute: If you keep lightweight log steps (such as logging record counts or transport file sizes) for production support, add a Boolean integration attribute (for example, Enable Verbose Logging) on the workday-in transport and set the log step's Execute When (execute-when) property on the Advanced tab to intsys.getAttributeAsBoolean('Enable Verbose Logging').

How kiweely fits

kiweely builds and refactors Workday Studio assemblies with structured error handling, cloud-log audit trails, and explicit Store + PutIntegrationMessage deliverable tagging. When an integration event fails or completes with warnings, kiweely inspects the event messages, server logs, and assembly flow in your sandbox tenant to isolate the root cause and verify the fix. Kiweely Personal is free in your Workday personal developer account and its tenant.

Frequently asked questions

Why did my integration event finish with a status of Completed, but the SFTP delivery step sent zero files?

If your store step relies on its default Create Document Reference = true setting, it invokes PutIntegrationMessage with is.document.deliverable set to false. The file appears on the Output Files tab of the integration event, but lacks the Deliverable tag required by the business process delivery service. Set Create Document Reference to false on the store step, save its output metadata to a variable, and pass that variable name into an explicit PutIntegrationMessage component via is.document.variable.name (where is.document.deliverable defaults to true).

Why did my PutIntegrationMessage messages stop appearing on the Integration Event Messages tab after 500 records?

Workday enforces a hard limit of 500 PutIntegrationMessage calls per integration event. After the 500th call, any PIM that only logs text (without attaching a document, specifying is.message.targets, or changing the overall event status) is silently redirected to the server log. Replace per-record PIM calls with a Cloud Log (cloud-log) step and persist the resulting HTML or CSV file once at the end of the event using a Store step.

Why did downstream steps fail with an unexpected SOAP body after adding PutIntegrationMessage?

PutIntegrationMessage uses the Mediation Message to construct its Put_Integration_Message web service request, overwriting whatever payload was previously in the Mediation Message. Either enable Clone Request (clone-request = true) on the Advanced tab of the PutIntegrationMessage component, or store your payload in a mediation context variable before calling PutIntegrationMessage.