Workday Core Connector: Worker (CCW) detects and exports incremental worker updates through a four-step change detection filter: it checks whether a qualifying event occurred in the Transaction Log (when enabled), verifies whether the worker meets Population Eligibility, evaluates whether the change is newly entered or newly effective between your launch date parameters, and confirms that at least one field selected for output (in Configure Integration Field Attributes or Field Overrides) actually changed. When an integration misses an expected update—such as an indirect organization change or a calculated field that depends on time or a related object—the cause is almost always that the Transaction Log service only evaluates workers who experienced a subscribed direct transaction event.
How the four-step change detection process works
Unlike a custom report that simply filters records between two dates, Core Connector: Worker compares the state of each worker at the current run boundaries against the state at the prior run boundaries. Every worker record must pass four sequential tests to appear in an incremental output file:
- Transaction Log check (if enabled): Did the worker experience at least one direct business process or transaction event that matches the types subscribed in Configure Integration Transaction Log within the launch window? (If the Transaction Log service is disabled, the connector skips this gate and performs a Full-Diff evaluation across all eligible workers.)
- Population Eligibility check: Does the worker satisfy the Boolean eligibility field
(
Is Trueor a customTrue/False Conditioncalculated field) configured in Configure Integration Population Eligibility (for DIS connectors) or the Define Eligibility field override (for non-DIS connectors)? - Launch Date boundary check: Was the change either newly effective (effective date falls
within the effective date window, and entered on or before
As Of Entry Moment) or newly entered (entered within the entry moment window, with an effective date on or beforeEffective Date)? - Output Field diff check: Did the value of at least one enabled Integration Field
Attribute or Integration Field Override differ between the starting boundary
(
Last Successfuldates) and the ending boundary (Currentdates)?
Configure the four date and time launch parameters
Incremental change detection requires four date/time launch parameters that define a two-dimensional comparison window (entry moment vs. effective date). When scheduling a recurring connector run via Launch / Schedule Integration, set Value Type to Determine Value at Runtime and assign the delivered dynamic fields below:
| Launch Parameter | Role in Change Detection | Recommended Scheduled Runtime Field | Full Extract / Manual Override Behavior |
|---|---|---|---|
Launch ParameterAs Of Entry Moment | Role in Change DetectionUpper entry-time boundary; ignores any transaction entered in Workday after this date and time | Recommended Scheduled Runtime FieldCurrent Moment (DateTime) | Full Extract / Manual Override BehaviorUsed by both Full Extract and change detection runs |
Launch ParameterEffective Date | Role in Change DetectionUpper effective-date boundary; ignores any transaction whose effective date is after this date | Recommended Scheduled Runtime FieldCurrent Effective Date | Full Extract / Manual Override BehaviorUsed by both Full Extract and change detection runs |
Launch ParameterLast Successful As Of Entry Moment | Role in Change DetectionLower entry-time boundary; captures retroactive or current-dated transactions entered since the last run | Recommended Scheduled Runtime FieldAs of Entry DateTime of Last Completed Integration Event | Full Extract / Manual Override BehaviorIgnored when Full Extract is checked; can be manually backdated (e.g., Current Moment minus 48 hours) |
Launch ParameterLast Successful Effective Date | Role in Change DetectionLower effective-date boundary; captures future-dated transactions that became effective since the last run | Recommended Scheduled Runtime FieldAs of Effective Date of Last Completed Integration Event | Full Extract / Manual Override BehaviorIgnored when Full Extract is checked; earliest valid Unix epoch date in Workday is January 1, 1970 |
Why manual test runs break scheduled change detection
The dynamic fields As of Entry DateTime of Last Completed Integration Event and
As of Effective Date of Last Completed Integration Event pull their timestamps from the most
recent completed run of that integration system—whether that run was launched by the scheduler or
manually by an administrator. If you launch an ad-hoc manual run in Production midday, the next
scheduled nightly run will use your midday run as its Last Successful baseline, skipping any
changes that occurred before your manual test. Always use a separate cloned integration system for
ad-hoc testing, or explicitly override the Last Successful parameters on the next scheduled run.
Transaction Log subscriptions vs. Full-Diff extracts
You can run Core Connector: Worker incremental change detection in two modes depending on whether the Transaction Log Service is enabled in Related Actions > Integration System > Configure Integration Services:
| Change Detection Mode | How It Evaluates Workers | Advantages | Limitations |
|---|---|---|---|
Change Detection ModeTransaction Log enabled (Configure Integration Transaction Log) | How It Evaluates WorkersScans the Workday transaction log first and only evaluates field diffs for workers who had a subscribed transaction type within the launch window | AdvantagesSignificantly faster runtime performance on large worker populations | LimitationsCannot detect indirect changes (changes on related objects not logged as a worker transaction) or time-based calculated field shifts unless a subscribed worker event also fires |
Change Detection ModeFull-Diff extract (Transaction Log service disabled, Full Extract = false) | How It Evaluates WorkersEvaluates every eligible worker in the population at both launch boundary points and outputs any worker whose included output fields changed | AdvantagesCaptures both direct and indirect changes, including organizational restructures, role reassignments, and calculated field changes | LimitationsHigher processing overhead because every eligible worker is compared across the two points in time |
Choosing Transaction Log subscription options
When the Transaction Log service is enabled, open Related Actions > Integration System > Configure Integration Transaction Log and choose one of five subscription scopes:
- Subscribe to all Business Processes: Captures events tied to any Workday business process type.
- Subscribe to all Business Process Types except: Captures all business process events except those you explicitly exclude.
- Subscribe to all Transaction Types: Captures all worker events in Workday, including non-business-process transactions.
- Subscribe to all Transaction Types except: Captures all events except excluded types (recommended when you want broad coverage while excluding noisy, irrelevant events).
- Subscribe to specific Transaction Types: Restricts the integration strictly to the listed
transaction types (for example,
Hire EmployeeandTerminate Employeefor an external badge provisioning feed).
Why calculated field and indirect changes do not fire without a subscribed event
One of the most frequent troubleshooting questions in Core Connector: Worker is why a worker's updated manager, job classification, or calculated field override did not appear in the daily change file.
There are two distinct causes:
- Indirect object changes do not write a Worker Transaction Log entry: When an administrator edits a Job Profile (such as changing a job classification), reorganizes a Supervisory Organization hierarchy, or changes a Manager assignable role on an organization, the transaction is logged against the Job Profile or Organization object—not the Worker object. If your CCW integration relies on the Transaction Log Service, step 1 of change detection never selects the affected workers unless those workers also happen to have a qualifying direct worker transaction in the same window.
- Calculated fields resolve dynamically at runtime and have no stored transaction: Workday
never stores calculated field values in the database and never writes a transaction log entry
when a calculated field's output changes (for example, a
Date Differencetenure calculation crossing 12 months, or aLookup Related Valuepulling a field from a related object).
How to fix missing indirect or calculated field changes:
- If your integration must detect indirect changes (such as manager role updates or job profile
edits) or standalone calculated field changes, disable the Transaction Log Service in
Configure Integration Servicesand run the connector as a Full-Diff extract (Full Extract = false), combined with the Data Initialization Service (DIS) for parallelized extraction performance. - In PECI integrations that run multiple times per day with the Transaction Log enabled, enable the Payroll Effective Change Interface - Effective Stack Sync Service so the final daily primary run captures indirect changes without duplicating earlier records.
Transaction effective-date nuances and Stack Processing
Even when a direct worker transaction is subscribed in the Transaction Log, certain Workday events follow special effective-date rules:
| Transaction Nuance | Affected Workday Events | Impact on Connector Output |
|---|---|---|
| Transaction NuanceImmediately effective upon entry (Effective Date appears blank on Worker History) | Affected Workday EventsPersonal Information Change, Marital Status Change | Impact on Connector OutputEffective the exact moment the change is submitted, regardless of any date entered on the form. |
Transaction NuanceEffective the day after the termination/end date (Effective Date + 1) | Affected Workday EventsTermination, End International Assignment | Impact on Connector OutputA worker remains active through the end of their termination date. A termination effective today (Effective Date = Today) becomes effective for change detection tomorrow (Effective Date + 1), unless your Effective Date launch parameter looks ahead. |
| Transaction NuanceLast day of leave vs. return date | Affected Workday EventsReturn From Leave | Impact on Connector OutputWorkday records the last day of leave as the effective date of the Return From Leave event, not the first day back at work. |
Top of Stack vs. Effective Stack processing
Connectors also differ in how they handle multiple changes to the same field within a single launch window:
- Top of Stack processing: Compares only the value at the start of the window
(
Last Successful) against the value at the end of the window (As Of/Effective Date), ignoring intermediate edits. If a worker's work worktag or contact field changes fromAtoBand back toAwithin the same day, Top of Stack sees identical start and end values (A == A) and outputs nothing. If it changes fromAtoBtoC, Top of Stack outputs onlyC(andAas the prior value if prior values are enabled). - Effective Stack processing: Recognizes and outputs every sequential effective change (
AtoB, thenBtoC) in order within the launch window.
Diagnose missing worker records with Connector Audit Files
Every Core Connector: Worker run attaches diagnostic files to the Output Files tab of the Integration Event:
Data Changes Audit: Lists the exact field-level changes detected for every worker included in incremental runs (not generated on Full Extract runs).Diagnostic Audit: Lists every worker instance evaluated by the integration event and why records were filtered or included. IfDiagnostic Auditis completely empty when running as the ISU, verify that the ISU has domain security access to the Population Eligibility field.Messages Audit: Contains the underlying web service requests and responses (or DIS data groups) for deep inspection.
How kiweely fits
kiweely audits your Core Connector: Worker configurations, Transaction Log subscriptions, Population Eligibility rules, and Field Override calculated fields in your sandbox tenant to explain why specific worker changes were included or skipped. It configures and tests DIS field overrides, launch parameter schedules, and downstream Document Transformation steps against real worker scenarios before production deployment. Kiweely Personal is free in your Workday personal developer account and its tenant.
Frequently asked questions
Why didn't Core Connector: Worker pick up a worker's Termination on the day of termination?
Workday considers a terminated worker active through the end of their termination date, so the
Termination (and End International Assignment) transaction takes effect on
Effective Date + 1 (the day after the termination date). If your daily connector runs with
Effective Date set to Current Effective Date, a termination dated today will appear in
tomorrow's change file.
Why did a change to a manager role or job profile fail to trigger a worker update in CCW?
Changes to assignable roles on organizations or classifications on job profiles are logged on the Organization or Job Profile object, not on the Worker object. When the Transaction Log Service is enabled, CCW only inspects workers who had a direct subscribed worker transaction. To capture indirect changes automatically, disable the Transaction Log service so CCW runs a Full-Diff comparison across all eligible workers.
What happens if someone runs a scheduled Core Connector: Worker integration manually in Production?
When a scheduled integration uses As of Entry DateTime of Last Completed Integration Event and
As of Effective Date of Last Completed Integration Event, those dynamic fields reference the last
successful run of the integration system—including manual runs. A manual run resets the baseline
timestamp, causing the next scheduled run to miss any changes that occurred before the manual
launch. Always run ad-hoc tests on a cloned integration system or manually adjust the
Last Successful launch parameters on the next scheduled execution.