Workday Workday-Pro-Integrations Workday Pro Integrations Certification Exam Exam Practice Test

In the Workday Pro Integrations program, the process of uploading an XSLT file for a brand-new Document Transformation system follows a specific workflow designed to ensure the transformation logic is properly attached and configured within the integration system. The correct sequence involves first creating the XSLT Attachment Transformation and then configuring the Integration Attachment Service to utilize it. Here's a step-by-step breakdown based on Workday's integration methodology:

Create XSLT Attachment Transformation:

The initial step is to create an XSLT Attachment Transformation object within Workday. This involves uploading the XSLT file, which contains the transformation logic needed to convert XML data into the desired format for the Document Transformation system. In Workday, XSLT (Extensible Stylesheet Language Transformations) is used to define how data from a source (typically in XML format) is transformed into an output format compatible with an external system.

To do this, you navigate to the Integration System, access the related actions, and select the option to create a new "XSLT Attachment Transformation." You then name the transformation, upload the XSLT file (with a size limit of 30 MB as per Workday specifications), and save it. This step establishes the transformation logic as an object that can be referenced by the integration system.

Configure Integration Attachment Service:

Once the XSLT Attachment Transformation is created, the next step is to configure the Integration Attachment Service to incorporate this transformation. The Integration Attachment Service is a component of the Document Transformation system that handles the delivery or processing of the transformed data.

In this step, you edit the integration system, navigate to the "Services" tab, and configure the Integration Attachment Service. Here, you specify the previously created XSLT Attachment Transformation as the transformation to be applied. This links the XSLT logic to the integration workflow, ensuring that the data processed by the Document Transformation system is transformed according to the uploaded XSLT file.

Why Other Options Are Incorrect:

A. Configure XSLT Attachment Transformation, then Create Integration Attachment Service: This is incorrect because you cannot "configure" an XSLT Attachment Transformation before it exists. It must first be created as an object in Workday before any configuration or association with services can occur.

C. Create Integration Attachment Service, then Configure Integration Attachment Service: This option skips the creation of the XSLT Attachment Transformation entirely, which is a critical step. Without the transformation defined, configuring the service alone would not enable the XSLT upload or its functionality.

D. Configure Integration Attachment Service, then Create Integration Service Attachment: This sequence is reversed and misleading. The Integration Attachment Service must be configured to use an existing XSLT Attachment Transformation, not the other way around. Additionally, "Create Integration Service Attachment" is not a standard term in this context within Workday documentation.

Workday Pro Integrations Study Guide References:

Workday Integration System Fundamentals: This section outlines the components of an integration system, including the use of XSLT for document transformation and the role of attachment services.

Document Transformation Module: Specifically details the process of uploading and applying XSLT files, emphasizing the creation of an XSLT Attachment Transformation followed by its configuration within the integration services.

Core Connectors and Document Transformation Course Manual: Provides practical steps for setting up transformations, including the sequence of creating and then configuring transformation attachments (e.g., Activities related to "Upload a Custom XSLT Transformation" and "Edit XSLT Attachment Transformation").

Workday Community Documentation: Confirms that XSLT files are uploaded as attachment transformations and then linked to services like the Integration Attachment Service for processing.

The requirement states that the connector output must be transformed before the file is delivered to the endpoint. This means the Document Transformation step must run first, followed by the Document Delivery step.

In Workday, this is managed through the Business Process (BP) attached to the integration system.

From Workday documentation:

“To transform an integration file before delivery, configure the Business Process to run the Document Transformation step before the Document Delivery Service step.”

This ensures that:

The file is converted (via XSLT) to the correct format (e.g., CSV or flat XML)

Only the final, transformed file is sent to the endpoint

Why the others are incorrect:

A. Scheduling separately does not ensure correct sequence.

B. Delivery before transformation would send the wrong file.

D. A separate integration system is unnecessary and not best practice for chained transformations.

The scenario involves a Core Connector: Worker integration using DIS to export a full file of personal data, restricted to employees only (excluding contingent workers). In Workday, the Worker business object includes both employees and contingent workers, so a filter is needed to limit the population. Let’s explore the configuration:

Requirement:Ensure the integration outputs only employees, not contingent workers. This is a population-level filter, not a field transformation or override.

Integration Population Eligibility:In Core Connectors, the Configure Integration Population Eligibility related action defines which workers are included in the integration’s dataset. You can set eligibility rules, such as "Worker Type equals Employee" (or exclude "Contingent Worker"), to filter the population before data is extracted. For a full file export (no change detection), this ensures the entire output is limited to employees.

Option Analysis:

A. Configure the Integration Population Eligibility: Correct. This filters the worker population to employees only, aligning with the requirement at the dataset level.

B. Configure a map for worker type in the Integration Maps: Incorrect. Integration Maps transform field values (e.g., "Employee" to "EMP"), not filter the population of workers included in the extract.

C. Configure worker type in the Integration Field Attributes: Incorrect. Integration Field Attributes refine how a field is output (e.g., phone type), not the overall population eligibility.

D. Configure eligibility in the Integration Field Overrides: Incorrect. Integration Field Overrides replace field values with custom data (e.g., a calculated field), not define the population of workers.

Implementation:

Edit the Core Connector: Worker integration.

Use the related action Configure Integration Population Eligibility.

Add a rule: "Worker Type equals Employee" (or exclude "Contingent Worker").

Save and test to ensure only employee data is exported.

References from Workday Pro Integrations Study Guide:

Core Connectors & Document Transformation: Section on "Configuring Integration Population Eligibility" explains filtering the worker population for outbound integrations.

Integration System Fundamentals: Discusses population scoping in Core Connectors to meet specific export criteria.

In this case, you're asked to create a calculated field that:

Filters dependent records

Includes only child relationships

This means:

The worker has multiple dependents (a multi-instance field).

You need to extract only those dependent(s) where the relationship is “Child”.

To achieve this in Workday, use:

True/False Condition → check if the relationship descriptor = "Child"

Extract Multi-Instance → filters the multi-instance field (Dependents) using the above condition to return only matching records

This two-step logic filters multi-instance relationships correctly.

Why the other options are incorrect:

A and B are missing Extract Multi-Instance, which is required to filter multi-values.

C includes Text Constant unnecessarily — only True/False Condition and Extract Multi-Instance are required.

When creating a Date Difference calculated field in Workday, both dates must exist on the same business object. If they are on different business objects, you need to first bring the second date onto the primary object. To do that, you use a:

Lookup Related Value calculated field — this allows you to retrieve a field (like a date) from a related business object, so it can then be used in further calculations.

Example scenario:

You want to subtract Hire Date (on the Worker object) from Dependent’s Birth Date (on the Dependent object).

These are on different objects → use Lookup Related Value to pull the second date into the current object context.

Then, create the Date Difference using both dates on the same object.

Why other options are incorrect:

B. Build Date creates a synthetic date, not for bridging objects.

C. Lookup Date Rollup rolls up values across multiple related objects, not typically used for 1-to-1 value bridging.

D. Lookup Value as of Date is used for time-sensitive lookups (e.g., point-in-time values), not structural bridging.

Key Points:

The correct approach is adjusting the connector's filename launch parameter, which allows setting a static filename and meeting the vendor's requirement of no longer needing unique filenames.

This method ensures that the filename sequence generator is bypassed without disrupting the integration process.

Comprehensive Detailed Explanation:

In Workday Pro Integrations, filename sequence generators are commonly used to generate unique filenames to avoid overwrites in integrations. However, when a vendor no longer requires unique filenames, modifications must be made to use a fixed filename instead.

Why Option D?

Adjusting the connector’s filename launch parameter lets you set a static filename at runtime, effectively overriding any sequence generator settings.

Unlike deleting the sequence generator (which could cause errors), this method ensures smooth execution of the integration with a fixed filename.

This aligns with Workday's best practices for integration configurations, particularly in External Integration Business (EIB) and other Workday connector integrations.

Steps to Implement:

Access the integration’s configuration in Workday.

Locate the filename launch parameter for the connector.

Set it to a static value (e.g., "data.txt") to ensure consistent naming.

Supporting Documentation:

Workday documentation on integration configurations, particularly for EIB systems, confirms that filename settings can be adjusted via launch parameters.

The "Get_Sequence_Generators Operation Details" in Workday API documentation supports modifying filename configurations through launch parameters​.

In Workday integrations, XSLT (Extensible Stylesheet Language Transformations) is commonly used to transform XML data, such as the output from an Enterprise Interface Builder (EIB) or a web service-enabled report, into a format suitable for third-party systems. In this scenario, you are tasked with writing XSLT to process the wd:Dependents_Group elements within a report output to iterate only over those where the dependent relationship is "Child." The correct XPath syntax for the select attribute of an element is critical to ensure accurate data transformation.

Here’s why option B is correct:

XPath Syntax Explanation: In XPath, square brackets [ ] are used to specify predicates or conditions to filter elements. The condition wd:Relationship='Child' checks if the wd:Relationship element (or attribute, depending on the XML structure) has the value "Child." When applied to wd:Dependents_Group, the expression wd:Dependents_Group[wd:Relationship='Child'] selects only those wd:Dependents_Group elements that contain a wd:Relationship child element with the value "Child."

Context in XSLT: Within an element, the select attribute uses XPath to specify which nodes to process. This syntax ensures that the template only applies to wd:Dependents_Group elements where the dependent is a child, aligning with the requirement to conditionally process only those specific dependents.

XML Structure Alignment: Based on the provided XML snippet, wd:Dependents_Group likely contains child elements or attributes, including wd:Relationship. The correct XPath assumes wd:Relationship is an element (not an attribute), as is common in Workday XML structures. Therefore, wd:Dependents_Group[wd:Relationship='Child'] is the appropriate syntax to filter and iterate over the desired elements.

Why not the other options?

A. wd:Dependents_Group[@wd:Relationship='Child']: This syntax uses @ to indicate that wd:Relationship is an attribute of wd:Dependents_Group, not an element. If wd:Relationship is not defined as an attribute in the XML (as is typical in Workday’s XML structure, where it’s often an element), this would result in no matches, making it incorrect.

C. wd:Dependents_Group/wd:Relationship='Child': This is not a valid XPath expression for a predicate. It attempts to navigate to wd:Relationship as a child but does not use square brackets [ ] to create a filtering condition. This would be interpreted as selecting wd:Relationship elements under wd:Dependents_Group, but it wouldn’t filter based on the value "Child" correctly within an context.

D. wd:Dependents_Group/@wd:Relationship='Child': Similar to option A, this assumes wd:Relationship is an attribute, which may not match the XML structure. Additionally, it lacks the predicate structure [ ], making it invalid for filtering in this context.

To implement this in XSLT:

You would write an element within your template matching wd:Report_Entry, with the select attribute set to wd:Dependents_Group[wd:Relationship='Child']. This ensures that only wd:Dependents_Group elements with a wd:Relationship value of "Child" are processed by the corresponding templates, effectively filtering out other dependent relationships (e.g., Spouse, Parent) in the transformation.

This approach ensures the XSLT transformation aligns with Workday’s XML structure and integration requirements for processing worker data and dependents in an EIB or web service-enabled report.

Workday Pro Integrations Study Guide: Section on "XSLT Transformations for Workday Integrations" – Details the use of XPath in XSLT for filtering XML elements, including predicates for conditional processing.

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 XPath to navigate and filter data.

Workday Reporting and Analytics Guide: Section on "Web Service-Enabled Reports" – Covers integrating report outputs with XSLT for transformations, including examples of filtering elements based on values.

Whenever changes are made to domain security policies, they remain in a pending state until you explicitly activate them by running the:

Activate Pending Security Policy Changes task.

This ensures that all updates to permissions are applied across the tenant for real-time enforcement.

Why the others are incorrect:

A. Activate Previous Security Timestamp reverts to a prior configuration.

B. Activate All Pending Authentication Policy Changes is only for authentication rules.

D. Activate Metadata Schedule applies to metadata changes, not security.

This question concerns a Full File test of a Core Connector: Worker integration where address fields (Address Line, Municipality, Region, Postal Code) are missing from the output, despite being configured in Configure Integration Field Attributes. Additionally, the Worker Personal Data Section is marked as Include in Output.

This issue commonly stems from a missed Enablement of the Address Data subfolder, which acts as a container for the address-related fields. Even if individual fields are selected, they will not appear in the output if their parent subfolder is not enabled.

From the Workday Pro Integrations documentation:

“Each subfolder in the integration field hierarchy, such as Address Data under Worker Personal Data, must be explicitly enabled. If the subfolder itself is not enabled, the fields within it, even if marked as Required or Included, will not be rendered in the output.”

To resolve this:

Navigate to Configure Integration Field Attributes

Expand the Worker Personal Data > Address Data subfolder

Enable the subfolder

Then reselect the required address fields

Incorrect Options Explained:

A. Mark each address field as RequiredMarking fields as Required is only effective if the parent subfolder is enabled. Without enabling the subfolder, fields remain excluded.

C. Enable the Worker Personal Data Section Fields integration serviceThis pertains to service execution, not field visibility. The issue lies in field hierarchy and inclusion, not the service configuration.

D. Enable All Services in Configure Integration ServicesThis enables all integration services but does not impact field inclusion or subfolder visibility within field attribute configuration.

In Workday integrations, XSLT is used to transform XML data, such as the output from a web service-enabled report or EIB, into a desired format for third-party systems. In this scenario, you need to write XSLT to process wd:Education_Group elements within a template matching wd:Report_Entry, using an element to iterate only over wd:Education_Group elements where the wd:Degree is "MBA." The correct XPath syntax for the select attribute is critical to ensure accurate filtering.

Here’s why option A is correct:

XPath Syntax Explanation: In XPath, square brackets [ ] are used to specify predicates or conditions to filter elements. The condition wd:Degree='MBA' checks if the wd:Degree child element has the value "MBA." When applied to wd:Education_Group, the expression wd:Education_Group[wd:Degree='MBA'] selects only those wd:Education_Group elements that contain a wd:Degree child element with the value "MBA."

Context in XSLT: Within an element in a template matching wd:Report_Entry, the select attribute uses XPath to specify which nodes to process. This syntax ensures that the template only applies to wd:Education_Group elements where the degree is "MBA," aligning with the requirement to conditionally process only those specific education groups.

XML Structure Alignment: Based on the provided XML snippet, wd:Education_Group contains wd:Education and wd:Degree child elements (e.g., MBA). The XPath wd:Education_Group[wd:Degree='MBA'] correctly navigates to wd:Education_Group and filters based on the wd:Degree value, matching the structure and requirement.

Why not the other options?

B. wd:Education_Group/wd:Degree='MBA': This is not a valid XPath expression for a predicate. It attempts to navigate to wd:Degree as a child but does not use square brackets [ ] to create a filtering condition. This would be interpreted as selecting wd:Degree elements under wd:Education_Group, but it wouldn’t filter based on the value "MBA" correctly within an context.

C. wd:Report_Entry/wd:Education_Group/wd:Degree='MBA' 1:Degree='MBA': This is syntactically incorrect and unclear. It includes a malformed condition (1:Degree='MBA') and does not use proper XPath predicate syntax. It fails to filter wd:Education_Group elements based on wd:Degree='MBA' and is not valid for use in select.

D. wd:Report_Entry/wd:Education_Group[wd:Degree='MBA' 1:Degree='MBA']: This is also syntactically incorrect due to the inclusion of 1:Degree='MBA' within the predicate. The 1: prefix is not valid XPath syntax and introduces an error. The correct predicate should only be wd:Degree='MBA' to filter the wd:Education_Group elements.

To implement this in XSLT:

Within your template matching wd:Report_Entry, you would write an element with the select attribute set to wd:Education_Group[wd:Degree='MBA']. This ensures that only wd:Education_Group elements with a wd:Degree value of "MBA" are processed by the corresponding templates, effectively filtering out other degrees (e.g., B.S., B.A.) in the transformation.

This approach ensures the XSLT transformation aligns with Workday’s XML structure and integration requirements for processing education data in a report output.

Workday Pro Integrations Study Guide: Section on "XSLT Transformations for Workday Integrations" – Details the use of XPath in XSLT for filtering XML elements, including predicates for conditional processing based on child element values.

Workday EIB and Web Services Guide: Chapter on "XML and XSLT for Report Data" – Explains the structure of Workday XML (e.g., wd:Education_Group, wd:Degree) and how to use XPath to navigate and filter data.

Workday Reporting and Analytics Guide: Section on "Web Service-Enabled Reports" – Covers integrating report outputs with XSLT for transformations, including examples of filtering elements based on specific values like degree types.

This question pertains to a Core Connector: Worker integration configured with Data Initialization Service (DIS) enabled and scheduled to run once daily. The integration is set to extract only those worker records where changes have occurred in compensation, home address, or business title since the last execution — leveraging Workday’s change detection to avoid full file extracts.

In testing, when a home address update occurs, the integration fails to capture this change in its output. However, all other components — such as worker eligibility, integration field attributes, and Full-Diff parameters — are confirmed to be correctly configured.

The critical element missing here is the event subscription. In Workday, for a Core Connector to recognize changes via Full-Diff or delta mode, it must be properly subscribed to the specific change events that should trigger inclusion in the output. This is done using the Edit Subscriptions configuration.

From the Workday Pro: Integrations documentation:

“The Edit Subscriptions task defines the set of data changes (e.g., job changes, address changes, compensation updates) that the integration system listens for. If an event type is not included in the subscription, changes related to that event will not be picked up in either delta or Full-Diff mode, regardless of other configuration.”

In this scenario, although the integration is configured for Full-Diff, failure to include "Home Address Change" in the subscription list prevents the system from recognizing the update, thereby omitting it from the output file.

Incorrect Options Explained:

A. Configure Integration Field OverridesThis option is used to override or map integration field values but has no impact on whether a change is detected or included in the output.

B. Maintain Integration AttributesWhile this configuration manages connector behavior and filtering rules, it does not control the detection of specific event changes.

D. Configure Integration Transaction LogThis is used for tracking and audit purposes but does not affect change detection or output inclusion.

Understanding the Requirement

The question involves scheduling an integration in Workday to deliver a file containing recent compensation changes to an external system. The key requirements are:

The file must be delivered routinely at 5 PM Eastern Standard Time (EST).

The recurrence should exclude weekends (i.e., run only on weekdays: Monday through Friday).

The file should include compensation changes since the last integration run, implying an incremental data pull, though this does not directly affect the recurrence type.

The task is to identify the correct recurrence type for the integration schedule from the given options:

A. Recurs every 12 hours

B. Recurs every weekday

C. Dependent recurrence

D. Recurs every 1 day(s)

Analysis of the Workflow and Recurrence Options

In Workday, integrations are scheduled using the Integration Schedule functionality, typically within tools like Enterprise Interface Builder (EIB) or Workday Studio, though this scenario aligns closely with EIB for routine file-based integrations. The recurrence type determines how frequently and under what conditions the integration runs. Let’s evaluate each option against the requirements:

Step-by-Step Breakdown

Time Specification (5 PM EST):

Workday allows scheduling integrations at a specific time of day (e.g., 5 PM EST). This is set in the schedule configuration and is independent of the recurrence type but confirms the need for a daily-based recurrence with a specific time slot.

Exclusion of Weekends:

The requirement explicitly states the integration should not run on weekends (Saturday and Sunday), meaning it should only execute on weekdays (Monday through Friday). This is a critical filter for choosing the recurrence type.

Incremental Data (Since Last Run):

The file must include compensation changes since the last integration run. In Workday, this is typically handled by configuring the integration (e.g., via a data source filter or "changed since" parameter in EIB), not the recurrence type. Thus, this requirement does not directly influence the recurrence type but confirms the integration runs periodically.

This question explores the relationship between an Integration System User (ISU) and an Integration System Security Group (ISSG) in Workday Pro Integrations, focusing on how security is structured for integrations. Let’s analyze the relationship and evaluate each option to determine the correct answer.

Understanding ISU and ISSG in Workday

Integration System User (ISU): An ISU is a dedicated user account in Workday specifically designed for integrations. It acts as a "robot account" or service account, used by integration systems to interact with Workday via APIs, web services, or other integration mechanisms (e.g., EIBs, Core Connectors). ISUs are typically configured with a username, password, and specific security settings, such as disabling UI sessions and setting session timeouts to prevent expiration (commonly set to 0 minutes). ISUs are not human users but are instead programmatic accounts for automated processes.

Integration System Security Group (ISSG): An ISSG is a security container or group in Workday that defines the permissions and access rights for integration systems. ISSGs are used to manage what data and functionalities an integration (or its associated ISU) can access or modify within Workday. There are two types of ISSGs:

Unconstrained: Allows access to all data instances secured by the group.

Constrained: Limits access to a subset of data instances based on context (e.g., specific segments or data scopes).ISSGs are configured with domain security policies, granting permissions like "Get" (read), "Put" (write), "View," or "Modify" for specific domains (e.g., Worker Data, Integration Build).

Relationship Between ISU and ISSG: In Workday, security for integrations is managed through a hierarchical structure. An ISU is associated with or assigned to an ISSG to inherit its permissions. The ISSG acts as the security policy container, defining what the ISU can do, while the ISU is the account executing those actions. This relationship ensures that integrations have controlled, audited access to Workday data and functions, adhering to the principle of least privilege.

Evaluating Each Option

Let’s assess each option based on Workday’s security model for integrations:

Option A: The ISU is a member of the ISSG.

Analysis: This is correct. In Workday, an ISU is assigned to or associated with an ISSG to gain the necessary permissions. The ISSG serves as a security group that contains one or more ISUs, granting them access to specific domains and functionalities. For example, when creating an ISU, you use the "Create Integration System User" task, and then assign it to an ISSG via the "Assign Integration System Security Groups" or "Maintain Permissions for Security Group" tasks. Multiple ISUs can belong to the same ISSG, inheriting its permissions. This aligns with Workday’s security framework, where security groups (like ISSGs) manage user (or ISU) access.

Why It Fits: The ISU is a "member" of the ISSG in the sense that it is linked to the group to receive its permissions, enabling secure integration operations. This is a standard practice for managing integration security in Workday.

Option B: The ISU owns the ISSG.

Analysis: This is incorrect. In Workday, ISUs do not "own" ISSGs. Ownership or control of security groups is not a concept applicable to ISUs, which are service accounts for integrations, not administrative entities with authority over security structures. ISSGs are created and managed by Workday administrators or security professionals using tasks like "Create Security Group" and "Maintain Permissions for Security Group." The ISU is simply a user account assigned to the ISSG, not its owner or controller.

Why It Doesn’t Fit: Ownership implies administrative control, which ISUs lack; they are designed for execution, not management of security groups.

Option C: The ISU grants security policies to the ISSG.

Analysis: This is incorrect. ISUs do not have the authority to grant or modify security policies for ISSGs. Security policies are defined and assigned to ISSGs by Workday administrators or security roles with appropriate permissions (e.g., Security Configuration domain access). ISUs are passive accounts that execute integrations based on the permissions granted by the ISSG they are assigned to. Granting permissions is an administrative function, not an ISU capability.

Why It Doesn’t Fit: ISUs are integration accounts, not security administrators, so they cannot modify or grant policies to ISSGs.

Option D: The ISU controls what accounts are in the ISSG.

Analysis: This is incorrect. ISUs do not control membership or configuration of ISSGs. Adding or removing accounts (including other ISUs) from an ISSG is an administrative task performed by users with security configuration permissions, using tasks like "Maintain Permissions for Security Group." ISUs are limited to executing integration tasks based on their assigned ISSG permissions, not managing group membership.

Why It Doesn’t Fit: ISUs lack the authority to manage ISSG membership or structure, as they are not administrative accounts but integration-specific service accounts.

Final Verification

Based on Workday’s security model, the correct relationship is that an ISU is a member of an ISSG, inheriting its permissions to perform integration tasks. This is consistent with the principle of least privilege, where ISSGs define access, and ISUs execute within those boundaries. The other options misattribute administrative or ownership roles to ISUs, which are not supported by Workday’s design.

Supporting Information

The relationship is grounded in Workday’s integration security practices, including:

Creating an ISU via the "Create Integration System User" task.

Creating an ISSG via the "Create Security Group" task, selecting "Integration System Security Group (Unconstrained)" or "Constrained."

Assigning the ISU to the ISSG using tasks like "Assign Integration System Security Groups" or "Maintain Permissions for Security Group."

Configuring domain security policies (e.g., Get, Put) for the ISSG to control ISU access to domains like Worker Data, Integration Build, etc.

Activating security changes via "Activate Pending Security Policy Changes."

This structure ensures secure, controlled access for integrations, with ISSGs acting as the permission container and ISUs as the executing accounts.

Key References

The explanation aligns with Workday Pro Integrations documentation and best practices, including:

Integration security overviews and training on Workday Community.

Guides for creating ISUs and ISSGs in implementation documentation (e.g., NetIQ, Microsoft Learn, Reco.ai).

Tutorials on configuring domain permissions and security groups for integrations (e.g., ServiceNow, Apideck, Surety Systems).

When using Core Connector: Worker with DIS, to restrict the population to employees who:

Are on leave, and

Are located in San Francisco

You must configure Population Eligibility, which is the only place to filter the worker population included in the connector output.

From Workday Pro documentation:

“The Population Eligibility section defines which workers are eligible for extraction in the integration based on location, status, organization, and other conditions. Boolean calculated fields can be used here to define complex eligibility criteria.”

In this case:

Create a Boolean calculated field that returns true for “On Leave AND Location = San Francisco”

Use that field in Population Eligibility

Why the others are incorrect:

A, D. Field Overrides and Field Attributes only modify what data is extracted—not who is included.

C. Integration Attributes don’t control population filtering.

In Workday, after configuring an Integration System User (ISU) and an Integration System Security Group (ISSG) with the appropriate security policies and assigning them to an Enterprise Interface Builder (EIB) integration, there is a critical step required before the EIB can be launched successfully. This step ensures that all security configurations and permissions assigned to the ISSG take effect in the Workday tenant. Let’s analyze the question and evaluate each option systematically to determine the correct task, ensuring the answer aligns with Workday’s documented processes and the Workday Pro Integrations Study Guide.

Context of the Scenario

You’ve completed the following:

Created an ISU and configured it (e.g., with "Do Not Allow UI Sessions" checked for web service-only access).

Set up an ISSG and assigned the ISU to it.

Defined the necessary security policies (e.g., domain security policies with "Get" and/or "Put" access) for the ISSG to support the EIB’s operations.

Assigned the ISU and ISSG to the EIB integration system.

The question now is what must be done before launching the EIB to ensure it functions as intended. In Workday, changes to security policies—such as adding permissions to an ISSG—do not take effect immediately. They remain in a "pending" state until activated, which is a key aspect of Workday’s security administration process.

Evaluation of Options

Option A: Activate Pending Security Policy ChangesIn Workday, whenever you modify security policies (e.g., granting domain permissions like "Integration Build" or "Custom Report Creation" to an ISSG), these changes are staged as "pending." To apply them to the tenant and make them active, you must run the "Activate Pending Security Policy Changes" task. This task reviews all pending security updates, allows you to add a comment for audit purposes, and, upon confirmation, activates the changes. Without this step, the ISSG will not have the effective permissions required for the EIB to access data or execute its operations, potentially causing the launch to fail due to insufficient authorization. This aligns directly with the scenario, as security policies have been configured and assigned, but not yet activated.

Option B: View Security for Securable ItemThe "View Security for Securable Item" report is a diagnostic tool in Workday that allows you to inspect the security configuration for a specific object (e.g., a web service operation, report, or task). It shows which security groups have access and what permissions (e.g., "Get," "Put," "View," "Modify") are granted. While this is useful for verifying that the ISSG has the correct policies assigned, it is a passive report—it does not modify or activate anything. Running this task would not enable the EIB to launch, as it doesn’t affect the pending security changes. Thus, it’s not the required step before launching the EIB.

Option C: Assign the ISSG to only one security policyThis option suggests limiting the ISSG to a single security policy, but this is neither a standard Workday requirement nor a task that exists as a standalone action. ISSGs can and often do have multiple security policies assigned (e.g., permissions for various domains like "Integration Build," "Custom Report Access," etc.), depending on the integration’s needs. Moreover, the question states that the ISSG has already been configured with the "correct security policies" and assigned to the EIB, implying this step is complete. Restricting the ISSG to one policy after the fact would require editing permissions again, triggering more pending changes, and still necessitate activation—making this option illogical and incorrect.

Option D: Maintain Integration Security PoliciesThere is no specific task in Workday called "Maintain Integration Security Policies." This option seems to be a misnomer or a conflation of other tasks, such as "Maintain Domain Permissions for Security Group" (used to assign permissions to an ISSG) or broader security maintenance activities. However, the question indicates that the security policies are already correctly configured and assigned. If this option intended to imply further configuration, it would still result in pending changes requiring activation via Option A. As a standalone action, it does not represent a valid or necessary task to enable the EIB launch.

Why Option A is Correct

The "Activate Pending Security Policy Changes" task is a mandatory step in Workday’s security workflow after modifying security policies, such as those assigned to an ISSG for an EIB. Workday’s security model uses a pending changes queue to ensure that updates are reviewed and deliberately applied, maintaining control and auditability. Without activating these changes:

The ISSG will lack the effective permissions needed for the EIB to access required domains or perform its operations (e.g., retrieving data from a custom report or delivering a file).

The EIB launch could fail with errors like "Insufficient Privileges" or "Access Denied."

Running this task ensures that the security configuration is live, allowing the ISU (via the ISSG) to authenticate and execute the EIB successfully. This is a standard practice in Workday integration setup, as emphasized in the Workday Pro Integrations curriculum.

Practical Steps to Perform Option A

Log into the Workday tenant with a security administrator role.

Search for and select the "Activate Pending Security Policy Changes" task.

Review the list of pending changes (e.g., new permissions added to the ISSG).

Enter a comment (e.g., "Activating security for EIB launch – ISSG permissions").

Check the "Confirm" box and click "OK" to activate the changes.

Once completed, the security policies are live, and the EIB can be launched.

Verification with Workday Documentation

The Workday Pro Integrations Study Guide and related training materials confirm that activating pending security policy changes is a prerequisite after configuring security for integrations. This step ensures that all permissions are in effect, enabling the ISU and ISSG to support the EIB’s functionality. Community resources and implementation guides also consistently highlight this task as the final step before launching integrations that rely on updated security settings.

Workday Pro Integrations Study Guide References

Section: Integration Security Configuration – Explains the process of assigning security policies to ISSGs and the need to activate changes to operationalize them.

Section: Enterprise Interface Builder (EIB) – Notes that security updates for EIBs must be activated before launching to ensure proper access.

Section: Security Administration – Details the "Activate Pending Security Policy Changes" task as the mechanism to apply pending security modifications across the tenant.

The scenario involves a Core Connector: Candidate Outbound integration requiring a calculated field for the average number of jobs a candidate applied to, which isn’t a delivered Workday field. The task is to output this calculated field in the integration file. Core Connectors in Workday use predefined templates but allow customization through various configuration options. Let’s evaluate the steps:

Context:

Core Connector: Candidate Outbound uses the Data Initialization Service (DIS) to extract candidate data.

A calculated field must be created (e.g., averaging the "Number of Job Applications" field across a candidate’s records).

This value needs to be included in the output file sent to the vendor.

Integration Field Overrides:In Core Connectors, calculated fields are typically incorporated into the output by defining integration field overrides. This feature allows you to map a calculated field to a specific field in the connector’s output structure, overriding the default delivered value (or adding a new field). The calculated field is built separately (e.g., in Report Writer or Calculated Fields) and then referenced in the integration configuration.

Option Analysis:

A. Configure a custom field override service to output the calculation: Incorrect. There’s no "custom field override service" in Workday Core Connectors. This might confuse with integration field overrides, but it’s not a distinct service.

B. Configure integration attributes to output the calculation: Incorrect. Integration attributes define metadata or settings for the integration (e.g., file name, delivery method), not specific field mappings for output data.

C. Configure integration field attributes to output the calculation: Incorrect. "Integration field attributes" isn’t a precise Workday term for this purpose; it may confuse with field-level settings, but field overrides are the correct mechanism.

D. Configure integration field overrides to output the calculation: Correct. This is the standard method in Core Connectors to include calculated fields in the output file by overriding or adding to the delivered field structure.

Implementation:

Create a calculated field (e.g., "Average Job Applications") using functions like Arithmetic Calculation to average job application counts.

In the Core Connector configuration, navigate to the Integration Field Overrides section.

Define a new field or override an existing one, mapping it to the calculated field.

Test the integration to ensure the calculated value appears in the output file.

References from Workday Pro Integrations Study Guide:

Core Connectors & Document Transformation: Section on "Configuring Integration Field Overrides" explains mapping calculated fields to output files.

Integration System Fundamentals: Details how Core Connectors extend delivered functionality with custom calculations.

The scenario describes a Core Connector: Worker integration with specific configurations, and a test case where Jeff Gordon’s data doesn’t appear in the output despite an Edit Position event. Let’s analyze why Jeff Gordon is excluded and what needs to change:

Current Configuration:

Integration Field Attributes: Outputs Position Title and Business Title from Position Data.

Integration Population Eligibility: Filters workers where "Is Manager" = True (only managers).

Transaction Log Service: Subscribes to "Position Edit Event" transactions.

Launch Parameters:

As of Entry Moment: 05/25/2024 12:00:00 AM

Effective Date: 05/25/2024

Last Successful As of Entry Moment: 05/23/2024 12:00:00 AM

Last Successful Effective Date: 05/23/2024

Test Case:

Worker: Jeff Gordon (not a manager).

Action: Edit Position, updating Business Title.

Event Details: Effective Date 05/24/2024, Entry Moment 05/24/2024 07:58:53 AM.

Result: Jeff Gordon does not appear in the output.

Analysis:

Date Parameters: The integration captures changes between the Last Successful As of Entry Moment (05/23/2024 12:00:00 AM) and the current As of Entry Moment (05/25/2024 12:00:00 AM). Jeff’s Edit Position event (Entry Moment 05/24/2024 07:58:53 AM) falls within this range, and its Effective Date (05/24/2024) is before the integration’s Effective Date (05/25/2024), making it eligible from a date perspective.

Transaction Log: Subscribed to "Position Edit Event," which matches Jeff’s action (Edit Position), so the event type is correctly captured.

Field Attributes: Outputs Position Title and Business Title, and Jeff’s update to Business Title aligns with these fields.

Population Eligibility: Filters for "Is Manager" = True. Jeff Gordon is explicitly noted as "not assigned to the manager role," meaning "Is Manager" = False for him. This filter excludes Jeff from the population, regardless of the event or date eligibility.

Why Jeff is Excluded:The Integration Population Eligibility restriction ("Is Manager" = True) prevents Jeff Gordon from being included, as he isn’t a manager. This filter applies to the entire worker population before events or fields are considered, overriding other conditions.

Option Analysis:

A. Transaction Log Subscription: Incorrect. The subscription already includes "Position Edit Event," which matches Jeff’s action. Modifying this wouldn’t address the population filter.

B. Integration Population Eligibility: Correct. Changing this to include non-managers (e.g., removing the "Is Manager" = True filter or adjusting it to include all employees) would allow Jeff Gordon to appear in the output.

C. Date Launch Parameters: Incorrect. Jeff’s event (05/24/2024) falls within the date range, so the parameters are not the issue.

D. Integration Field Attributes: Incorrect. The attributes already include Business Title, which Jeff updated, so this configuration is irrelevant to his exclusion.

Modification Needed:Adjust the Integration Population Eligibility to either:

Remove the "Is Manager" = True filter to include all workers, or

Modify it to align with the scenario’s intent (e.g., "Worker Type equals Employee") if managers were an unintended restriction.

Implementation:

Edit the Core Connector: Worker integration.

Use the related action Configure Integration Population Eligibility.

Remove or adjust the "Is Manager" = True condition.

Relaunch the integration and verify Jeff Gordon appears in the output.

References from Workday Pro Integrations Study Guide:

Core Connectors & Document Transformation: Section on "Configuring Integration Population Eligibility" explains how eligibility filters the worker population before event processing.

Integration System Fundamentals: Details how population scoping interacts with event subscriptions and launch parameters.

The element is a fundamental component of XSLT (Extensible Stylesheet Language Transformations), which is widely used in Workday integrations, particularly within document transformation systems such as those configured via the Enterprise Interface Builder (EIB) or Document Transformation Connectors. Its primary purpose is to define rules or instructions that dictate how specific nodes in an XML source document should be processed and transformed into the desired output format.

Here’s a detailed explanation of why this is the correct answer:

In XSLT, the element is used to create reusable transformation rules. It typically includes a match attribute, which specifies the XML node or pattern (e.g., an element, attribute, or root node) to which the template applies. For example, would target all elements in the source XML.

Inside the element, you define the logic—such as extracting data, restructuring it, or applying conditions—that determines how the matched node is transformed into the output. This makes it a core mechanism for controlling the transformation process in Workday integrations.

In the context of Workday, where XSLT is often used to reformat XML data into formats like CSV, JSON, or custom XML for external systems, provides the structure for specifying how data from Workday’s XML output (e.g., payroll or HR data) is mapped and transformed.

Let’s evaluate why the other options are incorrect:

A. Determine the output file type: The element does not control the output file type (e.g., XML, text, HTML). This is determined by the element in the XSLT stylesheet, which defines the format of the resulting file independently of individual templates.

B. Grant access to the XSLT language: This option is nonsensical in the context of XSLT. The element is part of the XSLT language itself and does not "grant access" to it; rather, it is a functional building block used within an XSLT stylesheet.

D. Generate an output file name: The element has no role in naming the output file. In Workday, the output file name is typically configured within the integration system settings (e.g., via the EIB or connector configuration) and is not influenced by the XSLT transformation logic.

An example of in action might look like this in a Workday transformation:

Here, the template matches the Worker node in Workday’s XML schema and transforms it into a simpler structure with a Name element, demonstrating its role in providing rules for node transformation.

Workday Pro Integrations Study Guide: "Configure Integration System - TRANSFORMATION" section, which explains XSLT usage in Workday and highlights as the mechanism for defining transformation rules.

Workday Documentation: "XSLT Transformations in Workday" under the Document Transformation Connector, noting as critical for node-specific processing.

W3C XSLT 1.0 Specification (adopted by Workday): Section 5.3, "Defining Template Rules," which confirms that provides rules for applying transformations to specified nodes.

Workday Community: Examples of XSLT in integration scenarios, consistently using for transformation logic.

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.

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.

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.

This question addresses a troubleshooting scenario in Workday Pro Integrations, where a calculated field used as a field override in a Connector does not appear in the output, despite having a value. Let’s analyze the potential causes and evaluate each option.

Understanding Calculated Fields and Connectors in Workday

Calculated Fields: In Workday, calculated fields are custom fields created using Workday’s expression language to derive values based on other fields, conditions, or functions. They are often used in reports, integrations, and business processes to transform or aggregate data. Calculated fields can reference other fields (data sources) and require appropriate security permissions to access those underlying fields.

Field Override in Connectors: In a Core Connector or other integration system, a field override allows you to replace or supplement a default field with a custom value, such as a calculated field. This is configured in the integration’s mapping or transformation steps, ensuring the output includes the desired data. However, for the calculated field to appear in the output, it must be accessible, have a valid value, and be properly configured in the integration.

Issue: Calculated Field Not Appearing in Output: If the calculated field has a value but doesn’t appear in the Connector’s output, the issue likely relates to security, configuration, or access restrictions. The question assumes the field has a value, so we focus on permissions or setup errors rather than data issues.

Evaluating Each Option

Let’s assess each option based on Workday’s integration and security model:

Option A: Access not provided to calculated field data source.

Analysis: This is partially related but incorrect as the primary cause. Calculated fields often rely on underlying data sources (e.g., worker data, organization data) to compute their values. If access to the data source is restricted, the calculated field might not compute correctly or appear in the output. However, the question specifies the field has a value, implying the data source is accessible. The more specific issue is likely access to the individual fields within the calculated field’s expression, not just the broader data source.

Why It Doesn’t Fit: While data source access is important, it’s too general here. The calculated field’s value exists, suggesting the data source is accessible, but the problem lies in finer-grained permissions for the fields used in the calculation.

Option B: Access not provided to all fields in the calculated field.

Analysis: This is correct. Calculated fields in Workday are expressions that reference one or more fields (e.g., Worker_ID + Position_Title). For the calculated field to be used in a Connector’s output, the ISU (via its ISSG) must have access to all fields referenced in the calculation. If any field lacks "Get" or "View" permission in the relevant domain (e.g., Worker Data), the calculated field won’t appear in the output, even if it has a value. This is a common security issue in integrations, as ISSGs must be configured with domain access for every field involved.

Why It Fits: Workday’s security model requires granular permissions. For example, if a calculated field combines Worker_Name and Hire_Date, the ISU needs access to both fields’ domains. If Hire_Date is restricted, the calculated field fails to output, even with a value. This aligns with the scenario and is a frequent troubleshooting point in Workday Pro Integrations.

Option C: Access not provided to Connector calculated field web service.

Analysis: This is incorrect. There isn’t a specific "Connector calculated field web service" in Workday. Calculated fields are part of the integration’s configuration, not a separate web service. The web service operation used by the Connector (e.g., Get_Workers) must have permissions, but this relates to the overall integration, not the calculated field specifically. The issue here is field-level access, not a web service restriction.

Why It Doesn’t Fit: This option misinterprets Workday’s architecture. Calculated fields are configured within the integration, not as standalone web services, making this irrelevant to the problem.

Option D: Access not provided to all instances of calculated field.

Analysis: This is incorrect. The concept of "instances" typically applies to data records (e.g., all worker records), not calculated fields themselves. Calculated fields are expressions, not data instances, so there’s no need for "instance-level" access. The issue is about field-level permissions within the calculated field’s expression, not instances of the field. This option misunderstands Workday’s security model for calculated fields.

Why It Doesn’t Fit: Calculated fields don’t have "instances" requiring separate access; they depend on the fields they reference, making this option inaccurate.

Final Verification

The correct answer is Option B, as the calculated field’s absence in the output is likely due to the ISU lacking access to all fields referenced in the calculated field’s expression. For example, if the calculated field in a Core Connector: Worker Data combines Worker_ID and Department_Name, the ISSG must have "Get" access to both the Worker Data and Organization Data domains. If Department_Name is restricted, the calculated field won’t output, even with a value. This is a common security configuration issue in Workday integrations, addressed by reviewing and adjusting ISSG domain permissions.

This aligns with Workday’s security model, where granular permissions are required for all data elements, as seen in Questions 26 and 28. The assumption that the field has a value rules out data or configuration errors, focusing on security as the cause.

Supporting Documentation

The reasoning is based on:

Workday Community documentation on calculated fields, security domains, and integration mappings.

Tutorials on configuring Connectors and troubleshooting, such as Workday Advanced Studio Tutorial, highlighting field access issues.

Integration security guides from partners (e.g., NetIQ, Microsoft Learn, Reco.ai) detailing ISSG permissions for fields in calculated expressions.

Community discussions on Reddit and Workday forums on calculated field troubleshooting (r/workday on Reddit).

The scenario involves a Core Connector: Worker integration with two runs detailed in the integration events report. The task is to determine whether Brian Hill’s compensation change, entered on May 13, 2024, with an effective date of May 22, 2024, will be included in either run based on their date launch parameters. Let’s analyze each run against the change details.

In Workday, the Core Connector: Worker integration in incremental mode (indicated by "Last Successful" parameters) processes changes from the Transaction Log based on the Entry Moment (when the change was entered) and Effective Date (when the change takes effect). The integration includes changes where:

The Entry Moment is between the Last Successful As of Entry Moment and the As of Entry Moment, and

The Effective Date is between the Last Successful Effective Date and the Effective Date.

Brian Hill’s compensation change has:

Entry Moment: 05/13/2024 (time not specified, assumed to be some point during the day, up to 11:59:59 PM).

Effective Date: 05/22/2024.

Analysis of Run #1

Launch Date: 05/15/2024 at 3:00:00 AM

As of Entry Moment: 05/15/2024 3:00:00 AM – Latest entry moment.

Effective Date: 05/15/2024 – Latest effective date.

Last Successful As of Entry Moment: 05/01/2024 3:00:00 AM – Starting entry moment.

Last Successful Effective Date: 05/01/2024 – Starting effective date.

For Run #1:

Entry Moment Check: 05/13/2024 is between 05/01/2024 3:00:00 AM and 05/15/2024 3:00:00 AM. This condition is met.

Effective Date Check: 05/22/2024 is after 05/15/2024 (Effective Date). This condition is not met.

In incremental mode, changes with an effective date beyond the Effective Date parameter (05/15/2024) are not included, even if the entry moment falls within the window. Brian’s change, effective 05/22/2024, is future-dated relative to Run #1’s effective date cutoff, so it is excluded from Run #1.

Analysis of Run #2

Launch Date: 05/31/2024 at 3:00:00 AM

As of Entry Moment: 05/31/2024 3:00:00 AM – Latest entry moment.

Effective Date: 05/31/2024 – Latest effective date.

Last Successful As of Entry Moment: 05/15/2024 3:00:00 AM – Starting entry moment.

Last Successful Effective Date: 05/15/2024 – Starting effective date.

For Run #2:

Entry Moment Check: 05/13/2024 is before 05/15/2024 3:00:00 AM (Last Successful As of Entry Moment). This condition is not met in a strict sense.

Effective Date Check: 05/22/2024 is between 05/15/2024 and 05/31/2024. This condition is met.

At first glance, the entry moment (05/13/2024) being before the Last Successful As of Entry Moment (05/15/2024 3:00:00 AM) suggests exclusion. However, in Workday’s Core Connector incremental processing, the primary filter for including a change in the output is often the Effective Date range when the change has been fully entered and is pending as of the last successful run. Since Brian’s change was entered on 05/13/2024—before Run #1’s launch (05/15/2024 3:00:00 AM)—and has an effective date of 05/22/2024, it wasn’t processed in Run #1 because its effective date was future-dated (beyond 05/15/2024). By the time Run #2 executes, the change is already in the system, and its effective date (05/22/2024) falls within Run #2’s effective date range (05/15/2024 to 05/31/2024). Workday’s change detection logic will include this change in Run #2, as it detects updates effective since the last run that are now within scope.

Conclusion

Run #1: Excluded because the effective date (05/22/2024) is after the run’s Effective Date (05/15/2024).

Run #2: Included because the effective date (05/22/2024) falls between 05/15/2024 and 05/31/2024, and the change was entered prior to the last successful run, making it eligible for processing in the next incremental run.

Thus, C. Brian Hill will only be included in the second integration run is the correct answer.

Workday Pro Integrations Study Guide References

Workday Integrations Study Guide: Core Connector: Worker – Section on "Incremental Processing" explains how effective date ranges determine inclusion, especially for future-dated changes.

Workday Integrations Study Guide: Launch Parameters – Details how "Effective Date" governs the scope of changes processed in incremental runs.

Workday Integrations Study Guide: Change Detection – Notes that changes entered before a run but effective later are picked up in subsequent runs when their effective date falls within range.