Pass the Workday Integrations Workday-Pro-Integrations Questions and answers with ValidTests

In XSLT, the processor applies transformation rules by matching nodes using XPath expressions inside statements.

“Templates define the rule, and XPath expressions determine which nodes they apply to.”

This is the foundational mechanism by which XSLT processes XML data.

Why the others are incorrect:

B. The element defines scope, not node matching.

C. invokes a named template but does not itself match nodes.

D. Namespace prefixes are used within XPath, but node matching is based on XPath.

The scenario involves a Core Connector: Worker integration using the Data Initialization Service (DIS) to export a full file of employee personal data. The vendor requires marital status values to be transformed from Workday’s internal text values (e.g., "Married," "Single") to a specific list of codes (e.g., "M," "S"), and any Workday value not matching the vendor’s list should output "OTHER." Let’s analyze the configuration:

Requirement:Transform the "Marital Status" field values into vendor-specific codes, with a fallback to "OTHER" for unmapped values. This is a field-level transformation, common in Core Connectors when aligning Workday data with external system requirements.

Integration Maps:In Core Connectors, Integration Maps are the primary tool for transforming field values. You create a map that defines source values (Workday’s marital status text) and target values (vendor’s codes). The "Default" setting in an integration map specifies what value to output if a Workday value isn’t explicitly mapped. Here, setting the default to "OTHER" ensures that any marital status not in the vendor’s list (e.g., a new Workday value like "Civil Union" not recognized by the vendor) is output as "OTHER."

Option Analysis:

A. Configure Integration Maps with a blank Default: Incorrect. A blank default would leave the field empty or pass the original Workday value for unmapped cases, not "OTHER," failing the requirement.

B. Configure Integration Attributes with a blank Default: Incorrect. Integration Attributes define integration-level settings (e.g., file name, delivery method), not field value transformations. They don’t support mapping or defaults for specific fields like marital status.

C. Configure Integration Maps with "OTHER" as a Default: Correct. This uses Integration Maps to map Workday values to vendor codes and sets "OTHER" as the default for unmapped values, meeting the requirement fully.

D. Configure Integration Attributes with "OTHER" as a Default: Incorrect. Integration Attributes don’t handle field-level transformations or defaults for data values, making this option inapplicable.

Implementation:

Edit the Core Connector: Worker integration.

Use the related action Configure Integration Maps.

Create a map for the "Marital Status" field (e.g., "Married" → "M," "Single" → "S").

Set the Default Value to "OTHER" in the map configuration.

Test the output to ensure mapped values use vendor codes and unmapped values return "OTHER."

References from Workday Pro Integrations Study Guide:

Core Connectors & Document Transformation: Section on "Configuring Integration Maps" explains mapping field values and using defaults for unmapped cases.

Integration System Fundamentals: Highlights how Core Connectors transform data to meet vendor specifications.

In Workday, a sequence generator is used to create unique, sequential identifiers for integration processes, such as Enterprise Interface Builders (EIBs). These identifiers are often needed to ensure data uniqueness or to meet external system requirements for tracking records. The question asks specifically about building a sequence generator for an EIB integration, so we need to identify the correct task based on Workday’s integration configuration framework.

Understanding Sequence Generators in Workday

A sequence generator in Workday generates sequential numbers or IDs based on predefined rules, such as starting number, increment, and format. These are commonly used in integrations to create unique identifiers for outbound or inbound data, ensuring consistency and compliance with external system requirements. For EIB integrations, sequence generators are typically configured as part of the integration setup to handle data sequencing or identifier generation.

Analyzing the Options

Let’s evaluate each option to determine which task is used to build a sequence generator for an EIB integration:

A. Put Sequence Generator Rule Configuration

Description: This option suggests configuring rules for a sequence generator, but "Put Sequence Generator Rule Configuration" is not a standard Workday task name or functionality. Workday uses specific nomenclature like "Create ID Definition/Sequence Generator" for sequence generator setup. This option seems vague or incorrect, as it doesn’t align with Workday’s documented tasks for sequence generators.

Why Not Correct?: It’s not a recognized Workday task, and sequence generator configuration is typically handled through a specific setup process, not a "put" or rule-based configuration in this context.

B. Create ID Definition/Sequence Generator

Description: This is a standard Workday task used to create and configure sequence generators. In Workday, you navigate to the "Create ID Definition/Sequence Generator" task under the Integrations or Setup domain to define a sequence generator. This task allows you to specify the starting number, increment, format (e.g., numeric, alphanumeric), and scope (e.g., tenant-wide or integration-specific). For EIB integrations, this task is used to generate unique IDs or sequences for data records.

Why Correct?: This task directly aligns with Workday’s documentation for setting up sequence generators, as outlined in integration guides. It’s the standard method for building a sequence generator for use in EIBs or other integrations.

C. Edit Tenant Setup - Integrations

Description: This task involves modifying broader tenant-level integration settings, such as enabling services, configuring security, or adjusting integration parameters. While sequence generators might be used within integrations, this task is too high-level and does not specifically address creating or configuring a sequence generator.

Why Not Correct?: It’s not granular enough for sequence generator setup; it focuses on tenant-wide integration configurations rather than the specific creation of a sequence generator.

D. Configure Integration Sequence Generator Service

Description: This option suggests configuring a service specifically for sequence generation within an integration. However, Workday does not use a task named "Configure Integration Sequence Generator Service." Sequence generators are typically set up as ID definitions, not as standalone services. This option appears to be a misnomer or non-standard terminology.

Why Not Correct?: It’s not a recognized Workday task, and sequence generators are configured via "Create ID Definition/Sequence Generator," not as a service configuration.

Conclusion

Based on Workday’s integration framework and documentation, the correct task for building a sequence generator for an EIB integration is B. Create ID Definition/Sequence Generator. This task allows you to define and configure the sequence generator with the necessary parameters (e.g., starting value, increment, format) for use in EIBs. This is a standard practice for ensuring unique identifiers in integrations, as described in Workday’s Pro Integrations training materials.

Surprising Insight

It’s interesting to note that Workday’s sequence generators are highly flexible, allowing customization for various use cases, such as generating employee IDs, transaction numbers, or integration-specific sequences. The simplicity of the "Create ID Definition/Sequence Generator" task makes it accessible even for non-technical users, which aligns with Workday’s no-code integration philosophy.

Key Citations

Workday Pro Integrations Study Guide, Module 3: EIB Configuration

Workday Integration Cloud Connect: Sequence Generators

Workday EIB and Sequence Generator Overview

Configuring Workday Integrations: ID Definitions

This scenario addresses an issue where a Core Connector: Worker integration — with DIS enabled and Full-Diff mode configured — unexpectedly includes terminated workers in the output, despite a requirement to include only active workers.

The correct step to address this issue is the configuration of Integration Population Eligibility.

From the Workday Pro: Integrations – Core Connector Configuration Guide, the relevant extract states:

“The Integration Population Eligibility step allows users to define which workers or populations are eligible to be included in the integration output. This includes filtering by worker status, organization, supervisory org, or other eligibility criteria. If this is not configured to exclude terminated workers, the integration will include all workers who meet the event conditions, regardless of their current status.”

Even though the integration uses change detection and the correct launch parameters, Workday still considers any worker with a qualifying change, including those terminated, unless they are explicitly excluded via eligibility rules.

Therefore, to prevent terminated workers from appearing in the output, you must set a filter in the Integration Population Eligibility step to include only active workers (e.g., using Worker.Status = Active or similar criteria).

Incorrect Options Explained:

A. Configure Integration Attributes... Include Inactive Workers in Full FileThis option would cause inactive (e.g., terminated) workers to be included when enabled. It doesn’t help filter them out.

B. Configure Integration Transaction Log... subscribe to everything except terminationSubscription controls which events trigger processing but does not control population eligibility. Terminated workers with address changes prior to termination could still appear if eligibility is not defined.

D. Configure Integration Field Overrides... use Eligibility CriterionField Overrides change data mappings or formats, not population eligibility. It cannot exclude terminated workers.

This question involves configuring an outbound connector using the Core Connector: Job Postings template in Workday Pro Integrations. We need to meet two specific vendor requirements:

Map worker subtype values according to the provided table (e.g., Seasonal (Fixed) = "S", Regular = "R", Contractor = "C", Consultant = "C", and any other value = "U").

Format the output file name as "CC_Job_Postings_dd-mm-yy_#.xml", where:

"dd" is the current day at runtime,

"mm" is the current month at runtime,

"yy" is the last two digits of the current year at runtime,

"#" is the current value of the sequencer at runtime.

Let’s break down the requirements and evaluate each option to determine the correct configuration steps.

Understanding the Requirements

1. Worker Subtype Mapping

The vendor provides a table for worker subtype values:

Internal Seasonal (Fixed) maps to "S"

Internal Regular maps to "R"

Internal Contractor maps to "C"

Internal Consultant maps to "C"

Any other value should be assigned "U"

In Workday, worker subtypes are typically part of the worker data, and for integrations, we use integration mappings to transform these values into the format required by the vendor. The integration mapping allows us to define how internal Workday values (e.g., worker subtypes) map to external values (e.g., "S", "R", "C", "U"). If no specific mapping exists for a value, we need to set a default value of "U" for any unmatched subtypes, as specified.

This mapping is configured in the integration system’s "Integration Mapping" or "Field Mapping" settings, depending on the template. For the Core Connector: Job Postings, we typically use the "Integration Mapping" feature to handle data transformations, including setting default values for unmapped data.

2. Output File Name Format

The vendor requires the output file to be named "CC_Job_Postings_dd-mm-yy_#.xml", where:

"CC_Job_Postings" is a static prefix,

"dd-mm-yy" represents the current date at runtime (day, month, last two digits of the year),

"#" is the current value from a sequence generator (sequencer) at runtime.

In Workday, file names for integrations are configured in the "File Utility" or "File Output" settings of the integration. To achieve this format:

The date portion ("dd-mm-yy") can be dynamically generated using Workday’s date functions or runtime variables, often configured in the File Utility’s "Filename" field with a "Determine Value at Runtime" setting.

The sequence number ("#") requires a sequence generator, which is enabled and configured to provide a unique incrementing number for each file. Workday uses the "Sequence Generator" feature for this purpose, typically accessed via the "Create ID Definition / Sequence Generator" task.

The Core Connector: Job Postings template supports these configurations, allowing us to set filename patterns in the integration’s setup.

Evaluating Each Option

Let’s analyze each option step by step, ensuring alignment with Workday Pro Integrations best practices and the vendor’s requirements.

Option A:

• Enable the Sequence Generator Field Attribute

• Configure the Sequence Generator

• Configure the Worker Sub Type Integration Mapping leaving the default value blank

Analysis:

Sequence Generator Configuration: Enabling the "Sequence Generator Field Attribute" and configuring the sequence generator is partially correct for the file name’s "#" (sequencer) requirement. However, "Sequence Generator Field Attribute" is not a standard term in Workday; it might refer to enabling a sequence generator in a field mapping, but this is unclear and likely incorrect. Sequence generators are typically enabled as an "Integration Service" or configured in the File Utility, not as a field attribute.

Worker Subtype Mapping: Configuring the worker subtype integration mapping but leaving the default value blank is problematic. The vendor requires any unmapped value to be "U," so leaving it blank would result in missing or null values, failing to meet the requirement.

Date in Filename: This option doesn’t mention configuring the date ("dd-mm-yy") in the filename, which is critical for the "CC_Job_Postings_dd-mm-yy_#.xml" format.

Conclusion: This option is incomplete and incorrect because it doesn’t address the default "U" for unmapped subtypes and lacks date configuration for the filename.

Option B:

• Enable the Integration Mapping Field Attribute

• Configure the Worker Sub Type Integration Mapping leaving the default value blank

• Configure the Sequence Generator

Analysis:

Sequence Generator Configuration: Configuring the sequence generator addresses the "#" (sequencer) in the filename, which is correct for the file name requirement.

Worker Subtype Mapping: Similar to Option A, leaving the default value blank for the worker subtype mapping fails to meet the vendor’s requirement for "U" as the default for unmapped values. This would result in errors or null outputs, which is unacceptable.

Date in Filename: Like Option A, there’s no mention of configuring the date ("dd-mm-yy") in the filename, making this incomplete for the full file name format.

Integration Mapping Field Attribute: This term is ambiguous. Workday uses "Integration Mapping" or "Field Mapping" for data transformations, but "Field Attribute" isn’t standard for enabling mappings. This suggests a misunderstanding of Workday’s configuration.

Conclusion: This option is incomplete and incorrect due to the missing default "U" for worker subtypes and lack of date configuration for the filename.

Option C:

• Enable the Integration Mapping Integration Service

• Configure the Worker Sub Type Integration Mapping and include a default value of "U"

• Configure the Sequence Generator

Analysis:

Sequence Generator Configuration: Configuring the sequence generator is correct for the "#" (sequencer) in the filename, addressing part of the file name requirement.

Worker Subtype Mapping: Including a default value of "U" for the worker subtype mapping aligns perfectly with the vendor’s requirement for any unmapped value to be "U." This is a strong point.

Date in Filename: This option doesn’t mention configuring the date ("dd-mm-yy") in the filename, which is essential for the "CC_Job_Postings_dd-mm-yy_#.xml" format. Without this, the file name requirement isn’t fully met.

Integration Mapping Integration Service: Enabling the "Integration Mapping Integration Service" is vague. Workday doesn’t use this exact term; instead, integration mappings are part of the integration setup, not a separate service. This phrasing suggests confusion or misalignment with Workday terminology.

Conclusion: This option is partially correct (worker subtype mapping) but incomplete due to the missing date configuration for the filename and unclear terminology.

Option D:

• Enable the Sequence Generator Integration Service

• Configure the Sequence Generator

• Configure the Worker Sub Type Integration Mapping and include a default value of "U"

Analysis:

Sequence Generator Configuration: Enabling the "Sequence Generator Integration Service" and configuring the sequence generator addresses the "#" (sequencer) in the filename. While "Sequence Generator Integration Service" isn’t a standard term, it likely refers to enabling and configuring the sequence generator functionality, which is correct. In Workday, this is done via the "Create ID Definition / Sequence Generator" task and linked in the File Utility.

Worker Subtype Mapping: Configuring the worker subtype integration mapping with a default value of "U" meets the vendor’s requirement for any unmapped value, ensuring "S," "R," "C," or "U" is output as specified in the table. This is accurate and aligns with Workday’s integration mapping capabilities.

Date in Filename: Although not explicitly mentioned in the steps, Workday’s Core Connector: Job Postings template and File Utility allow configuring the filename pattern, including dynamic date values ("dd-mm-yy"). The filename "CC_Job_Postings_dd-mm-yy_#.xml" can be set in the File Utility’s "Filename" field with "Determine Value at Runtime," using date functions and the sequence generator. This is a standard practice and implied in the configuration, making this option complete.

Conclusion: This option fully addresses both requirements: worker subtype mapping with "U" as the default and the file name format using the sequence generator and date. The terminology ("Sequence Generator Integration Service") is slightly non-standard but interpretable as enabling/configuring the sequence generator, which is correct in context.

Final Verification

To confirm, let’s summarize the steps for Option D and ensure alignment with Workday Pro Integrations:

Enable the Sequence Generator Integration Service: This likely means enabling and configuring the sequence generator via the "Create ID Definition / Sequence Generator" task, then linking it to the File Utility for the "#" in the filename.

Configure the Sequence Generator: Set up the sequence generator to provide incremental numbers, ensuring each file has a unique "#" value.

Configure the Worker Sub Type Integration Mapping with a default value of "U": Use the integration mapping to map Internal Seasonal (Fixed) to "S," Regular to "R," Contractor to "C," Consultant to "C," and set "U" as the default for any other value. This is done in the integration’s mapping configuration.

Filename Configuration (Implied): In the File Utility, set the filename to "CC_Job_Postings_dd-mm-yy_#.xml," where "dd-mm-yy" uses Workday’s date functions (e.g., %d-%m-%y) and "#" links to the sequence generator.

This matches Workday’s documentation and practices for the Core Connector: Job Postings template, ensuring both requirements are met.

Why Not the Other Options?

Options A and B fail because they leave the default worker subtype value blank, not meeting the "U" requirement.

Option C fails due to missing date configuration for the filename and unclear terminology ("Integration Mapping Integration Service").

Option D is the only one that fully addresses both the worker subtype mapping (with "U" default) and implies the filename configuration, even if the date setup isn’t explicitly listed (it’s standard in Workday).

Supporting Documentation

The reasoning is based on Workday Pro Integrations best practices, including:

Workday Tutorial: Activity Creating Unique Filenames from EIB-Out Integrations – Details on using sequence generators for filenames.

Workday Tutorial: EIB Features – Explains integration mappings and default values.

Get_Sequence_Generators Operation Details – Workday API documentation on sequence generators.

Workday Advanced Studio Tutorial – Covers Core Connector templates and file name configurations.

r/workday Reddit Post: How to Create a New Sequence Generator for Filename for EIB – Community insights on sequence generators.

The scenario involves a Core Connector: Worker integration using DIS to export a full file of employee personal data, with the requirement to output only the home phone number when including phone data. Workday’s "Phone Number" field is multi-instance, meaning a worker can have multiple phone types (e.g., Home, Work, Mobile). Let’s determine the configuration:

Requirement:Filter the multi-instance "Phone Number" field to include only the "Home" phone number in the output file. This involves specifying which instance of the phone data to extract.

Integration Field Attributes:In Core Connectors, Integration Field Attributes allow you to refine how multi-instance fields are handled in the output. For the "Phone Number" field, you can set an attribute like "Phone Type" to "Home" to ensure only home phone numbers are included. This is a field-level configuration that filters instances without requiring a calculated field or override.

Option Analysis:

A. Configure an integration map to map the phone type: Incorrect. Integration Maps transform field values (e.g., "United States" to "USA"), not filter multi-instance data like selecting a specific phone type.

B. Include the phone type integration field attribute: Correct. This configures the "Phone Number" field to output only instances where the phone type is "Home," directly meeting the requirement.

C. Configure the phone type integration attribute: Incorrect. "Integration attribute" refers to integration-level settings (e.g., file format), not field-specific configurations. The correct term is "integration field attribute."

D. Configure an integration field override to include phone type: Incorrect. Integration Field Overrides are used to replace a field’s value with a calculated field or custom value, not to filter multi-instance data like phone type.

Implementation:

Edit the Core Connector: Worker integration.

Navigate to the Integration Field Attributes section for the "Phone Number" field.

Set the "Phone Type" attribute to "Home" (or equivalent reference ID for Home phone).

Test the output file to confirm only home phone numbers are included.

References from Workday Pro Integrations Study Guide:

Core Connectors & Document Transformation: Section on "Integration Field Attributes" explains filtering multi-instance fields like phone numbers by type.

Integration System Fundamentals: Notes how Core Connectors handle multi-instance data with field-level attributes.

In Workday integrations, XSLT is used to transform XML data, such as the output from an Enterprise Interface Builder (EIB) or a web service-enabled report, into a desired format for third-party systems. In this scenario, you need to write XSLT to process wd:Dependents_Group elements and output a relationship code based on the value of the wd:Relationship attribute or element. The requirement is to output "SP" for a "Spouse" relationship, "CH" for a "Child" relationship, and "OTHER" for any other relationship, using an statement within a template matching wd:Dependents_Group.

Here’s why option C is correct:

XSLT Structure: The element in XSLT provides conditional logic similar to a switch statement. It evaluates conditions in elements sequentially, executing the first matching condition, and uses for any case that doesn’t match.

Relationship as an Attribute: Based on the provided XML snippet, wd:Relationship is an attribute (e.g., Spouse within wd:Dependents_Group). However, in Workday XML for integrations, wd:Relationship is often represented as an attribute (@wd:Relationship) rather than a child element, especially in contexts like dependent data in reports. The syntax @wd:Relationship in the test attribute of correctly references this attribute, aligning with Workday’s typical XML structure for such data.

Condition Matching:

The first SP checks if the wd:Relationship attribute equals "Spouse" and outputs "SP" if true.

The second CH checks if the wd:Relationship attribute equals "Child" and outputs "CH" if true.

The OTHER handles all other cases, outputting "OTHER" if the relationship is neither "Spouse" nor "Child."

Context in Template: Since the template matches on wd:Dependents_Group, the test conditions operate on the current wd:Dependents_Group element and its attributes, ensuring the correct relationship code is output for each dependent. The XML snippet shows wd:Relationship as an element, but Workday documentation and integration practices often standardize it as an attribute in XSLT transformations, making @wd:Relationship appropriate.

Why not the other options?

A.

xml

WrapCopy

SP

CH

OTHER

This assumes wd:Relationship is a child element of wd:Dependents_Group, not an attribute. The XML snippet shows wd:Relationship as an element, but in Workday integrations, XSLT often expects attributes for efficiency and consistency, especially in report outputs. Using wd:Relationship without @ would not match the attribute-based structure commonly used, making it incorrect for this context.

B.

xml

WrapCopy

SP

CH

OTHER

This correctly uses @wd:Relationship for an attribute but has a logical flaw: if wd:Relationship='Child', the second would output "CH," but the order of conditions matters. However, the primary issue is that it doesn’t match the exact structure or intent as clearly as option C, and Workday documentation often specifies exact attribute-based conditions like those in option C.

D.

xml

WrapCopy

SP

CH

OTHER

This uses an absolute path (/wd:Relationship), which searches for a wd:Relationship element at the root of the XML document, not within the current wd:Dependents_Group context. This would not work correctly for processing dependents in the context of the template matching wd:Dependents_Group, making it incorrect.

To implement this in XSLT:

Within your template matching wd:Dependents_Group, you would include the statement from option C to evaluate the wd:Relationship attribute and output the appropriate relationship code ("SP," "CH," or "OTHER") based on its value. This ensures the transformation aligns with Workday’s XML structure and integration requirements for processing dependent data in an EIB or web service-enabled report, even though the provided XML shows wd:Relationship as an element—XSLT transformations often normalize to attributes for consistency.

Workday Pro Integrations Study Guide: Section on "XSLT Transformations for Workday Integrations" – Details the use of , , , and XPath for conditional logic in XSLT, including handling attributes like @wd:Relationship.

Workday EIB and Web Services Guide: Chapter on "XML and XSLT for Report Data" – Explains the structure of Workday XML (e.g., wd:Dependents_Group, @wd:Relationship) and how to use XSLT to transform dependent data, including attribute-based conditions.

Workday Reporting and Analytics Guide: Section on "Web Service-Enabled Reports" – Covers integrating report outputs with XSLT for transformations, including examples of conditional logic for relationship codes.

The scenario describes a Core Connector: Worker integration configured to output specific fields (Position Title and Business Title) for workers who meet the Integration Population Eligibility criteria (Is Manager = true) and where the Transaction Log service is subscribed to the "Position Edit Event." The integration is launched with specific date parameters, and a test edit is made to Jared Ellis’ position, who is a manager. However, despite the edit being completed with an effective date of 05/24/2024 and an entry moment of 05/24/2024 07:58:53 AM, Jared does not appear in the output. Let’s analyze why and determine the correct configuration element to modify.

In Workday integrations, the Core Connector: Worker uses change detection mechanisms to identify and process updates based on the Transaction Log and date launch parameters. The Transaction Log service captures events such as the "Position Edit Event" and records them with an Effective Date (when the change takes effect) and an Entry Moment (when the change was entered into the system). The integration’s date launch parameters define the time window for which changes are retrieved:

As of Entry Moment: 05/25/2024 12:00:00 AM – This specifies the latest point in time for when changes were entered into Workday.

Effective Date: 05/25/2024 – This defines the date for which the changes are effective.

Last Successful As of Entry Moment: 05/23/2024 12:00:00 AM – This indicates the starting point for entry moments from the last successful run.

Last Successful Effective Date: 05/23/2024 – This indicates the starting point for effective dates from the last successful run.

For an incremental run (like this one, since "Last Successful" parameters are provided), Workday processes changes where the Entry Moment falls between the Last Successful As of Entry Moment (05/23/2024 12:00:00 AM) and the As of Entry Moment (05/25/2024 12:00:00 AM), and where the Effective Date falls between the Last Successful Effective Date (05/23/2024) and the Effective Date (05/25/2024).

Now, let’s evaluate Jared Ellis’ edit:

Entry Moment: 05/24/2024 07:58:53 AM – This falls within the range of 05/23/2024 12:00:00 AM to 05/25/2024 12:00:00 AM.

Effective Date: 05/24/2024 – This falls within the range of 05/23/2024 to 05/25/2024.

At first glance, Jared’s edit seems to fit the date parameter window. However, the issue lies in the time component of the date launch parameters. Workday interprets these parameters with precision down to the second. The As of Entry Moment is set to 05/25/2024 12:00:00 AM (midnight), which is the very start of May 25, 2024. Jared’s Entry Moment of 05/24/2024 07:58:53 AM is correctly within the range from 05/23/2024 12:00:00 AM to 05/25/2024 12:00:00 AM. However, the Transaction Log subscription to "Position Edit Event" relies on the change being fully processed and available in the log by the time the integration runs.

The integration might have run at a point where the effective date window or the subscription logic did not correctly capture the event due to a mismatch in how the Effective Date is evaluated against the Last Successful Effective Date. Specifically, if the integration only processes changes with an Effective Date strictly after the Last Successful Effective Date (05/23/2024) up to the Effective Date (05/25/2024), and the logic excludes changes effective exactly on 05/24/2024 due to a boundary condition or a timing issue in the transaction log, Jared’s change might not be picked up.

To resolve this, modifying the Date launch parameters is necessary. Adjusting the As of Entry Moment to a later time (e.g., 05/25/2024 11:59:59 PM) or ensuring the Effective Date range explicitly includes all changes effective on or after 05/23/2024 through 05/25/2024 would ensure Jared’s edit is captured. This adjustment aligns the time window to include all relevant transactions logged before the integration run.

Let’s evaluate the other options:

A. Integration Population Eligibility: This is set to "Is Manager = true," and Jared is a manager. This filter is working correctly and does not need modification.

B. Integration Field Attributes: These are configured to output Position Title and Business Title, and the edit was to the Job Profile (part of Position Data). The fields are appropriately configured, so this is not the issue.

D. Transaction Log Subscription: The subscription is set to "Position Edit Event," which matches Jared’s edit. The subscription type is correct, so no change is needed here.

Thus, the issue stems from the date launch parameters not fully encompassing the timing of Jared’s edit in the Transaction Log, making C. Date launch parameters the correct answer.

Workday Pro Integrations Study Guide References

Workday Integrations Study Guide: Core Connector: Worker – Section on "Change Detection Using Transaction Log" explains how Transaction Log subscriptions filter events based on date parameters.

Workday Integrations Study Guide: Launch Parameters – Details the role of "As of Entry Moment" and "Effective Date" in defining the scope of incremental runs.

Workday Integrations Study Guide: Incremental Processing – Describes how "Last Successful" parameters establish the baseline for detecting changes in subsequent runs.

The XML fragment shown follows the Report‑as‑a‑Service (RaaS) structure typical for Workday custom report output:

Megan McNeil

25

7507df6a99664ce7bc0cb902cf370543

Child

Inside each , the target value Relationship_ID resides under:

wd:Dependents_Group

→ wd:Relationship

→ wd:ID (wd:type="Relationship_ID")

When writing the template:

XSLT uses a relative XPath (starting with ./) to navigate from the matched node.

Therefore, the correct XPath should be:

/wd:Dependents_Group/wd:Relationship/wd:ID

That expression selects the wd:ID element so you can then test/extract where wd:type="Relationship_ID".

Why the other options are incorrect:

Option

Why Incorrect

A & B

These use an equality test incorrectly inside the XPath expression — they would not return the node value and are syntactically invalid for value extraction.

C

Missing ./ — would still work in many cases, but Workday XSLT best practice is to use relative paths when inside a match.

Workday Pro Integration guidance for RaaS/XSLT stresses:

Always scope node selection relative to the current context tree using prefix‑qualified XPath expressions.

When creating an outbound connector using the Workday Core Connector: Organization Outbound template, you need to configure the connector to meet specific vendor requirements, such as formatting output data and adjusting document retention policies. Let's break down the question and analyze the requirements and options based on Workday's integration framework, specifically focusing on the Core Connector and its configuration tasks.

Understanding the Requirements

Output Data Formatting:The vendor has provided a table specifying how organization types should appear in the output file (e.g., Cost Center as "CC", Pay Group as "PAY", Supervisory as "S", and any other value as "OTHER"). This indicates a need to transform or map Workday organization data into specific output values, which is typically handled by configuring how fields are processed or mapped in the integration.

Document Retention Policy Change:The vendor wants to change the default document retention policy from 30 days to 7 days. In Workday, document retention policies for integrations (e.g., files stored on SFTP or other delivery methods) are managed through integration settings, specifically attributes related to file retention or delivery options.

Analyzing Workday Core Connector: Organization Outbound

The Core Connector: Organization Outbound template is a pre-built Workday integration template used to extract organization-related data (e.g., cost centers, pay groups, supervisory organizations) and send it to an external system. It leverages Workday's integration framework, including integration maps, field overrides, and attributes, to customize data output and behavior.

Integration Maps: Used to define how data is transformed or mapped from Workday to the output format, often involving XSLT or predefined mappings.

Integration Field Overrides: Allow you to override or customize how specific fields are displayed or formatted in the output, such as mapping "Cost Center" to "CC" as per the vendor's table.

Integration Attributes: Control broader integration settings, such as delivery methods, file formats, and retention policies (e.g., document retention duration).

Integration Field Attributes: Typically focus on specific field-level properties but are less commonly used for retention policies or broad mappings compared to the above options.

Evaluating the Vendor's Output Requirements

The table provided (Cost Center → "CC", Pay Group → "PAY", Supervisory → "S", any other value → "OTHER") suggests a need to transform or override the default output values for organization types. This is a field-level customization, best handled by Integration Field Overrides, which allow you to specify custom values or formats for specific fields in the output.

For example, in the Core Connector, you can use Integration Field Overrides to map the Workday organization type (e.g., "Cost_Center") to the vendor's desired output ("CC"). This is a common practice for outbound integrations where external systems require specific formatting.

Evaluating the Retention Policy Change

The default document retention policy of 30 days needs to be changed to 7 days. In Workday, retention policies for integration output files (e.g., files delivered via SFTP or email) are configured as part of the integration's attributes, not field-level settings.

Integration Attributes are used to manage integration-wide settings, including delivery options, file retention periods, and other global configurations. You can specify the retention period (e.g., 7 days) in the attributes section of the Core Connector configuration.

This is distinct from field-level overrides or maps, as retention is not tied to individual data fields but to the integration's output management.

Analyzing the Options

Now, let's evaluate each option to determine which tasks are needed to meet both requirements:

A. Configure Integration Maps and Configure Integration Attributes

Integration Maps: These are used for broader data transformations or mappings, such as converting Workday XML to another format or defining complex data relationships. While they could theoretically handle the output value mappings (e.g., Cost Center → "CC"), they are typically more complex and less granular than field overrides for simple value changes.

Integration Attributes: Correct for configuring the retention policy (e.g., changing from 30 to 7 days), as attributes manage integration-wide settings like retention.

Why Not Sufficient?: Integration Maps are overkill for simple field value overrides like the vendor's table, and field-level customization is better handled by Integration Field Overrides for precision and ease.

B. Configure Integration Field Overrides and Configure Integration Field Attributes

Integration Field Overrides: Correct for mapping specific field values (e.g., Cost Center → "CC"), as they allow granular control over output formats for individual fields.

Integration Field Attributes: These are less commonly used and typically focus on field-specific properties (e.g., data type, length), not broad integration settings like retention policies. Retention is not managed at the field level, so this is incorrect for the retention requirement.

Why Not Sufficient?: Integration Field Attributes do not handle retention policies, making this option incomplete.

C. Configure Integration Field Overrides and Configure Integration Attributes

Integration Field Overrides: Perfect for mapping the vendor's output values (e.g., Cost Center → "CC", Pay Group → "PAY", etc.), as they allow precise control over field-level output formatting.

Integration Attributes: Correct for configuring the retention policy (e.g., changing from 30 to 7 days), as attributes manage integration-wide settings like file retention.

Why Sufficient?: This combination addresses both requirements—field-level output formatting and integration-wide retention policy changes—making it the most accurate choice.

D. Configure Integration Maps and Configure Integration Field Attributes

Integration Maps: As explained, these are better for complex transformations, not simple field value overrides like the vendor's table. They could work but are less efficient than field overrides.

Integration Field Attributes: As noted, these do not handle retention policies or broad integration settings, making them incorrect for the retention requirement.

Why Not Sufficient?: This combination fails to address retention effectively and uses Integration Maps when Integration Field Overrides would be more appropriate for the output formatting.

Conclusion

Based on the analysis, the vendor's requirements for output formatting (mapping organization types to specific values) and changing the retention policy (from 30 to 7 days) are best met by:

Integration Field Overrides: To customize the output values for organization types (e.g., Cost Center → "CC") as shown in the table.

Integration Attributes: To adjust the document retention policy from 30 days to 7 days.