Workday Cloud Connect for Benefits and Payroll: Field Overrides and Integration Maps

Workday Cloud Connect packages—including Cloud Connect for Benefits (CCB), Payroll Effective Change Interface (PECI), and Core Connectors—deliver prebuilt integration templates that cannot be modified at the code level, but provide four tenant-configurable customization layers: Integration Attributes, Integration Field Attributes, Integration Maps, and Integration Field Overrides. You use Integration Maps (Integration System > Configure Integration Maps) to translate tenanted Workday values into external vendor codes, and Integration Field Overrides (Integration System > Configure Integration Field Overrides) to attach custom fields, report fields, or calculated fields when a vendor requires data or formatting not delivered by the standard template.

Understand the four connector customization layers

Before creating calculated fields or adding a downstream Document Transformation step, identify which connector building block controls the requirement. You access all four tasks from the integration system's Related Actions > Integration System menu:

To inspect every service, attribute, and map delivered by a template before building the integration, run the Integration Template Catalog report in Workday and select View Details on the target template.

Configure Integration Maps and handle unmapped values

Integration Maps translate Workday's internal representation of a business object or reference value into the exact code expected by a benefits carrier or payroll provider. The integration services enabled on your template determine which maps appear when you open Related Actions > Integration System > Configure Integration Maps.

Typical Integration Maps in Benefits (CCB) and Core Connectors

• ANSI X12 834 v2 (CCB): Requires mapping Loop2000_INS02 - Individual Relationship Code, Loop2100A_DMG03 - Gender Code, Loop2100A_DMG04 - Marital Status Code, Loop2300_HD03 - Insurance Line Code for Standard Loop, and Loop2300_HD05 - Coverage Level Code.
• COBRA connectors: Map qualifying events (use the COBRA Eligibility Reasons report to list all tenanted reasons), enrollment relationships, coverage levels, and Plan Bundle Name (when Bundle Plans Based on Group is set to TRUE).
• CCB with Payroll Data: Adds payroll-specific maps including Employer Contribution Level, Pay Cycle Frequency, Election Amount Indicator, Compensation Source Code, and Combine Enrollment Records.

Fixing unmapped value errors and using Default Value

When a worker record contains a Workday value that has not been mapped in Configure Integration Maps (for example, a newly created Benefit Coverage Level or Marital Status), connector behavior depends on the template:

1. Silent pass-through vs Completed with Errors: Some connectors allow unmapped values to pass through or omit the tag without raising an event error, while others finish with a status of Completed with Errors (or Completed with Warnings) and list the offending worker instances in the Diagnostic Audit file or event Messages tab.
2. Fast discovery on initial setup: When configuring a new Cloud Connect for Benefits integration, launch a test run immediately after creating the system; the event Messages tab explicitly lists which essential maps are missing values for your tenanted plans.
3. Configure the Map Default Value deliberately: Every Integration Map provides a Default Value field alongside the Internal/External value grid. Setting a distinct sentinel string (such as UNMAPPED or a vendor-approved fallback code) in Default Value guarantees that newly introduced Workday values do not blank out required segments, and makes unmapped records easy to spot during audit file validation.

Configure Integration Field Overrides

When an external vendor requires a value that is not exposed by any delivered field attribute—or requires multiple Workday fields concatenated, substringed, or conditionally evaluated—use an Integration Field Override.

Non-DIS vs DIS-enabled connectors

How you set up a field override depends on whether the connector uses the Data Initialization Service (DIS):

1. Standard (non-DIS) connectors: Configuring a field override is a two-step process:
   • Run Related Actions > Integration System > Configure Integration Services, scroll to the Custom Integration Services grid, add a row, and select Create Integration Field Override Service. Provide a service name, description, and the primary business object (such as Worker or Position).
   • Open Related Actions > Integration System > Configure Integration Field Overrides, locate your custom service or template override slot, and select the replacement Workday report field, custom field, or system-wide calculated field.
2. DIS-enabled connectors (such as PECI and DIS-enabled Core Connector: Worker): Field override support is built directly into the Data Initialization Service. You do not need to create a separate custom integration service—go straight to Related Actions > Integration System > Configure Integration Field Overrides and map your calculated field to the extended field slot.
3. Packaged CCB templates (such as ANSI X12 834 v2): Predefine named field override slots that correspond to specific file loops, segments, and elements (for example, extensible Loop 1000A Sponsor, Loop 1000B Payer, Loop 1000C TPA/Broker, and Loop 2000 elements). Each override slot accepts a single field on the designated business object.

Using calculated fields and Document Builder with Field Overrides

Because each field override slot accepts only one field reference, any multi-branch logic must be synthesized inside a single calculated field (typically using Evaluate Expression, True/False Condition, Concatenate Text, Format Date, or Extract Single Instance + Lookup Related Value). Always validate your calculated field on a custom report alongside its source fields before attaching it to a connector.

Keep three performance rules in mind when attaching calculated fields to connectors:

• The 30-override performance threshold: Workday resolves calculated fields at runtime for every qualifying worker. If a connector requires more than 30 field overrides backed by calculated fields, runtime performance degrades substantially—consider using Document Builder (for DIS connectors) or switching to a custom Workday Studio integration.
• Use Document Builder for multi-instance related objects on DIS connectors: Rather than building chains of Extract Single Instance calculated fields to pull multi-instance data (such as Dependents), run the Create Document Builder task, set the Context Business Object (for example, Dependent), and attach the Document Builder to a Sub Document inside the connector's Field Override Services.
• Avoid heavy history report fields in PECI: Never use Worker Events Completed, Worker History, Staffing History - All, or Staffing History - Approved as source fields in PECI calculated fields; they load massive background history stacks and can cause PECI runs to time out or throw exceptions. Use the Worker Event History with Filter Parameters report field instead and populate the Transaction Log Types prompt on the extended field in DIS field overrides.

Test Integration System User (ISU) security on Field Overrides

A common production failure occurs when a field override works during an administrator's test run, but outputs blank tags when the scheduled integration runs under its Integration System User (ISU) and Integration System Security Group (ISSG). Connector security documentation only lists the domains required for delivered template fields; any calculated field or report field attached to a Field Override requires separate domain permissions for its underlying secured fields.

How to verify Field Override access

1. Locate the calculated field used in the override and select Related Actions > Calculated Field > View Security Groups (or Security > View Security / the View Security for Securable Item report) to identify the domain security policies that secure its underlying delivered or custom fields.
2. Add the connector's ISSG to those domain security policies and run Activate Pending Security Policy Changes.
3. On the integration system, run Related Actions > Integration Field Override > Test Security (the Test Security for Document Field Overrides task) to verify whether every override field shows Accessible by User = Yes for the assigned ISU.

The DIS security testing nuance (Get vs View)

When securing an ISSG on a domain security policy, you can grant either Integration Permissions (Get / Put) or Report/Task Permissions (View / Modify).

• At runtime, granting Integration Get permission works for both non-DIS and DIS-based connectors—the override data will populate in the output file.
• However, because DIS-based connectors evaluate report fields rather than SOAP web services, running Integration Field Override > Test Security in the Workday UI on a DIS-based connector will report Accessible by User = No if the ISSG only has Get Integration permission. Grant the ISSG Report/Task View permission on the underlying domain so the UI security tester accurately reports Yes.
• If a DIS connector finishes with Completed with Warnings and logs a DIS Exception Detected message, run Related Actions > Integration Event > Retrieve Technical Files on the event to inspect the exception log for the exact field or population eligibility permission that failed.

How kiweely fits

kiweely inspects your tenant's connector templates, calculated field hierarchies, and ISSG domain permissions to configure Integration Maps and Field Overrides without trial-and-error launches. It builds and validates the required calculated fields against real worker records in your sandbox and checks ISU access so override tags never go blank in production. Kiweely Personal is free in your Workday personal developer account and its tenant.

Frequently asked questions

Why is my Field Override value appearing in custom reports for my user, but missing from the connector output file?

The Integration System User (ISU) running the connector lacks domain security permissions for one or more delivered or custom fields referenced inside your calculated field. Run Related Actions > Calculated Field > View Security Groups on the override field, grant the connector's ISSG View (and Get) access on the securing domain policy, run Activate Pending Security Policy Changes, and verify access using Related Actions > Integration Field Override > Test Security.

Where do I configure Population Eligibility when Data Initialization Service (DIS) is enabled?

On non-DIS connectors, you filter workers using the Define Eligibility field override. Once DIS is enabled on a worker-based connector, Workday ignores the Define Eligibility field override. Instead, open Related Actions > Integration System > Configure Integration Population Eligibility and select a Boolean report field or True/False Condition calculated field on the Worker business object (or select the delivered Is True field to include all workers).

Should I use a named vendor 834 template or the ANSI X12 834 v2 template for a new benefits carrier?

Always select the standard ANSI X12 834 V2 template for any benefits integration that requires an 834 EDI file format, unless a specific non-834 partner template is required. Workday no longer enhances legacy named-vendor 834 templates and deprecates them in favor of the configurable ANSI X12 834 V2 template.