Free Workday-Pro-Integrations Practice Test Questions 2026

Explanation:

This question tests the fundamental structural requirements for a valid XSLT stylesheet used in Workday integrations (and per XSLT standards). Every XSLT file must be a well-formed XML document that the processor can recognize and execute as a transformation.

✅ Correct Option:

B. A root element, namespace, and at least one template
A valid XSLT file requires a single root element (typically or ), the mandatory XSLT namespace declaration (xmlns:xsl="http://www.w3.org/1999/XSL/Transform"), and at least one element that defines the transformation rules. These three elements ensure the file is well-formed, recognizable by the processor, and functional.

❌ Incorrect options:

A. A root element, namespace, and at least one transformation
“Transformation” is not a specific required element. The stylesheet itself performs the transformation; the required construct is one or more templates that contain the rules.

C. A header, a footer, and a namespace
Headers and footers are optional output-formatting constructs (often implemented inside templates), not mandatory structural features of an XSLT file.

D. A template, a prefix, and a header
A prefix is only part of a namespace declaration and is not independently required. A header is optional and not a core validity requirement.

🔧 Reference:
→ W3C XSLT 3.0 Specification – Stylesheet Structure & XSLT Namespace
Confirms that a stylesheet must be a well-formed XML document using the XSLT namespace and containing template rules.

Explanation:

This question tests your ability to use Workday's Element Transformation and Validation (ETV) attributes within an XSLT Document Transformation (DT). The requirement is to format the ps:Position_ID field to a fixed length of 10 characters and report truncation as an error. ETV attributes must be applied directly to the specific element being formatted (Pos_ID), not to parent elements or the template itself. The correct approach places both etv:fixedLength="10" and etv:reportTruncation="error" on the Pos_ID element while correctly extracting the value using the XPath ps:Position_Data/ps:Position_ID.

✔️ Correct Option: D
This option correctly applies both ETV attributes (etv:reportTruncation="error" and etv:fixedLength="10") directly to the Pos_ID element that requires formatting and validation. It also correctly extracts the ps:Position_ID value using the proper XPath. ETV attributes must be placed on the specific data element, not the template or parent element.

❌ Incorrect Option: A
— This option includes etv:fixedLength="10" on the correct element but omits the required etv:reportTruncation="error" attribute. Without this attribute, the integration cannot report truncated values as errors, which fails the requirement.

❌ Incorrect Option: B
— This misplaces the etv:fixedLength="10" attribute on the parent Position element instead of the Pos_ID field. ETV attributes must be applied to the specific field being formatted, not its parent element.

❌ Incorrect Option: C
This option also misplaces etv:fixedLength="10" on the template element itself. XTT/ETV attributes cannot be applied to . They must be placed on the specific output element (Pos_ID) that requires the formatting and validation logic.

🔧 Reference:
→ Workday Pro Integrations Study Guide: Document Transformation (DT) and ETV — Confirms that ETV attributes like fixedLength and reportTruncation must be applied directly to the specific field element being formatted, not to parent elements or the template.

→ Workday Core Connector and EIB Guide: XML Transformations — Details how to use ETV attributes for fixed-length formatting and truncation validation when transforming position data with XSLT templates.

Explanation:

This question tests the role of the element in XSLT processing. Templates define the instructions that XSLT applies when a particular node or pattern in the source XML is matched, controlling how that source data is transformed into the desired output.

🟢 Correct Option:

C. Provide rules to apply to a specified node.
The element defines a set of processing rules for nodes that match its match pattern or are invoked by name. When the XSLT processor encounters a matching node, it executes the template's instructions to create or modify the transformation output. Templates are therefore central to controlling how source XML is processed and transformed.

🔴 Incorrect options:

A. Determine the output file type.
This option is incorrect because does not determine the output file type. Output settings are controlled using elements such as , which can specify formats such as XML, HTML, or text. Templates instead define the processing logic applied to matching source nodes.

B. Grant access to the XSLT language.
This option is incorrect because access to XSLT functionality is established through the XSLT namespace declaration on the stylesheet. The element does not enable or authorize use of the XSLT language; it defines transformation instructions for selected source nodes.

D. Generate an output file name.
This option is incorrect because does not define the name of an output file. File naming and output destinations depend on the processing environment or specific output mechanisms. Templates are responsible for generating transformation content rather than determining where or under what filename it is saved.

🔧 Reference:
→ W3C XSLT Specification — xsl:template — Defines templates as rules for processing source nodes that match specified patterns.

Explanation:

This question tests your knowledge of outbound Enterprise Interface Builder (EIB) configuration options in Workday. It evaluates whether you can distinguish between native Workday-delivered file formatting options and user-defined custom transformations.

✅ Correct Option:

Option A:
Option A is correct because Alternate Output Format is a Workday-delivered feature configured during the Get Data step when using a custom report. It automatically converts report data into formats like CSV or Excel without requiring custom XSLT code.

❌ Incorrect options:

Option B:
Option B is incorrect because XSLT Attachment Transformation requires a user-created XSL stylesheet uploaded to the EIB, making it a custom-developed transformation rather than a Workday-delivered one.

Option C:
Option C is incorrect because Custom Transformation requires user-defined transformation logic (typically custom XSLT code) to process the data, so it is not pre-built by Workday.

Option D:
Option D is incorrect because Custom Report Transformation is a custom transformation type where the user defines custom delimited or fixed-width rules using XSL or placeholders, rather than relying on a simple built-in report output setting.

🔧 Reference:
→ Workday Community Documentation confirms that selecting an Alternate Output Format allows an outbound EIB to generate CSV or Excel files directly from report output.

Explanation:

This question tests your knowledge of the specific Workday task required to update the XSLT file for an existing Document Transformation integration system. When you need to replace or update the transformation logic without recreating the entire integration, you must use a task designed specifically for managing XSLT attachments within the context of document transformation .

✔️ Correct Option: C
Edit XSLT Attachment Transformation — This task allows users to upload a revised XSLT file directly to an existing Document Transformation integration system . It specifically targets the transformation logic (XSLT) rather than general attachments, ensuring the updated file replaces the previous version while maintaining the integration configuration .

❌ Incorrect Option: A
Edit Integration Attachment — This task manages general attachments like input files or supplementary documents associated with an integration, but it does not specifically handle XSLT transformation files . It lacks the precision required for updating transformation logic.

❌ Incorrect Option: B
Edit Integration Attachment Service — This is not a recognized task within Workday's integration framework. The terminology appears to be a mix of different task names and does not align with documented processes for managing XSLT files .

❌ Incorrect Option: D
Edit Integration Service Attachment — While this option might sound plausible, it is not the correct task for handling XSLT files in a Document Transformation context. Workday documentation consistently specifies "Edit XSLT Attachment Transformation" for this purpose .

🔧 Reference:
→ Workday Pro Integrations Study Guide: Configure Integration Systems - Transformations — Confirms that "Edit XSLT Attachment Transformation" is the task used to upload a new XSLT file for an existing document transformation integration system .

→ Workday Community Documentation: Enterprise Interface Builder (EIB) and Document Transformation Connector — Details the process for updating XSLT files, including the use of the "Edit XSLT Attachment Transformation" task .

Explanation:

This question tests the correct use of XPath predicates inside an select attribute to filter repeating elements in Workday RaaS (Report-as-a-Service) XML. The goal is to process only those wd:Dependents_Group nodes under the current wd:Report_Entry that represent a Child relationship.

✅ Correct Option:

B. wd:Dependents_Group[wd:Relationship='Child']
The square-bracket predicate [wd:Relationship='Child'] filters the wd:Dependents_Group elements to those that contain a child element named wd:Relationship whose string value is “Child”. This is the standard XPath syntax used in Workday XSLT when Relationship appears as an element (common in report output).

❌ Incorrect options:

A. wd:Dependents_Group[@wd:Relationship='Child']
The @ symbol tests for an attribute. If wd:Relationship is an element rather than an attribute, this expression returns no nodes.

C. wd:Dependents_Group/wd:Relationship='Child'
This is not a valid filter expression for a select attribute; it attempts a path comparison rather than a predicate and will not select the desired nodes.

D. wd:Dependents_Group/@wd:Relationship='Child'
This syntax is invalid for selecting elements; it mixes a path with an equality test and does not use a proper predicate.

🔧 Reference:
→ Workday Pro Integrations exam discussion and XPath guidance for RaaS output
Confirms that the predicate form element[child-element='value'] is the correct syntax when Relationship is modeled as an element inside wd:Dependents_Group.

Explanation:

This question tests your knowledge of XPath functions used in XSLT transformations within Workday. It evaluates whether you can apply the correct syntax and parameter ordering for the format-date function to convert date formats.

✅ Correct Option:

Option B:
Option B is correct because the format-date function expects the date value as its first argument (wd:Job_Profile_Data/wd:Effective_Date) and the picture string specifying the format pattern ('[D01]-[M01]-[Y0001]') as its second argument.

❌ Incorrect options:

Option A:
Option A is incorrect because it reverses the required parameter order, incorrectly supplying the picture formatting string as the first argument instead of the target date value.

Option C:
Option C is incorrect because the picture string '[M01]-[D01]-[Y0001]' formats the date in month-day-year order rather than the requested day-month-year format.

Option D:
Option D is incorrect because it both reverses the parameter order and uses a month-first picture string instead of the requested day-month-year pattern.

🔧 Reference:
→ W3C XPath Functions and Operators Specification confirms that the format-date function defines the target date value as the first argument and the formatting picture string as the second argument.

Explanation:

This question tests your understanding of Workday's security model for calculated fields in integrations. Specifically, it addresses why a calculated field configured as a field override might not appear in connector output despite having valid data.

✔️ Option B: Access not provided to all fields in the calculated field
In Workday, calculated field security is inherited from the underlying secured fields used in the calculation. If the Integration System User (ISU) lacks "Get" or "View" permission to any referenced field in the calculated field's expression, the entire calculated field will be suppressed from the output. This occurs even when the calculated field itself is properly configured and contains values. doc.workday.com: Securing Connectors confirms that underlying secured fields determine security access to a calculated field definition.

❌ Option A: Access not provided to calculated field data source
This option is incorrect because calculated fields do not have independent "data sources" with separate security policies. Security is controlled at the domain level for the underlying fields referenced in the calculation, not at a calculated-field-specific data source level.

❌ Option C: Access not provided to Connector calculated field web service
This option is incorrect because there is no dedicated "Connector calculated field web service" in Workday's architecture. Field overrides use the same web service operation as the connector (e.g., GetPositions), and security is governed by domain policies for the fields, not a separate calculated field service.

❌ Option D: Access not provided to all instances of calculated field
This option is incorrect because calculated field security is not instance-based. Access is determined by domain permissions for the underlying secured fields across all instances. If the ISU has proper domain access, the calculated field will appear for all eligible instances.

🔧 Reference:
→ Securing Connectors – doc.workday.com — Confirms that users with access to underlying secured fields can access calculated field values, and domain security determines access.

→ Enhance Integrations with Calculated Fields – doc.workday.com — Explains how calculated fields work in integrations and their dependency on underlying field security.

Explanation:

This question tests knowledge of the required and common attributes on the root element of an XSLT stylesheet. The (or ) element is the outermost element of any valid XSLT file and must declare the XSLT version along with the necessary namespace(s).

✅ Correct Option:

A. XSLT Version & Namespaces
The version attribute (e.g., version="1.0", version="2.0", or version="3.0") is required on the element to indicate the XSLT version. Namespace declarations (most importantly xmlns:xsl="http://www.w3.org/1999/XSL/Transform" and any additional namespaces such as Workday’s wd:) are also placed on this element so the processor can recognize XSLT instructions and source data.

❌ Incorrect options:

B. XSLT Version & Encoding
Encoding is specified in the XML declaration () at the very top of the file, not as an attribute of .

C. XML Version & Namespaces
The XML version belongs to the XML prolog/declaration, not to the stylesheet element.

D. Namespaces & Encoding
Encoding is not an attribute of ; it appears only in the XML declaration.

🔧 Reference:
→ W3C XSLT Specification – Stylesheet Element
Confirms that the version attribute is required on xsl:stylesheet and that namespace declarations (including the XSLT namespace) are placed on this element.

Explanation:

This question tests your ability to write an XPath expression within an element to conditionally process XML nodes. The goal is to iterate over only the wd:Education_Group elements where the degree is "MBA". Based on the provided XML structure, wd:Degree is a child element of wd:Education_Group, not an attribute. Therefore, the correct XPath uses a predicate [wd:Degree='MBA'] to filter elements where the child element wd:Degree has the value "MBA".

✔️ Correct Option: A
wd:Education_Group[wd:Degree='MBA'] — This is the correct XPath syntax. It selects all wd:Education_Group elements that are children of the current context node (the wd:Report_Entry) and have a child element named wd:Degree with the exact string value "MBA". This effectively filters the nodeset to only the relevant education groups.

❌ Incorrect Option: B
wd:Education_Group/wd:Degree='MBA' — This is syntactically invalid for a predicate inside the select expression. It would be interpreted as a path that returns a boolean or a node-set to compare, not as a filter condition. A valid filter requires brackets [] to apply the condition.

❌ Incorrect Option: C
wd:Report_Entry/wd:Education_Group/wd:Degree='MBA' — This option contains multiple issues. First, it redundantly specifies wd:Report_Entry even though the current context is already the wd:Report_Entry node. Second, it incorrectly places the comparison ='MBA' outside of predicate brackets [], making the XPath invalid for filtering in this context.

❌ Incorrect Option: D
wd:Report_Entry/wd:Education_Group[wd:Degree='MBA' 1:Degree='MBA'] — This option contains a nonsensical syntax error with 1:Degree='MBA', which is not valid XPath. Additionally, it redundantly specifies wd:Report_Entry when the current context is already within that node. The extra comparison makes the expression invalid and unprocessable.

🔧 Reference:
→ W3C XML Path Language (XPath) 2.0 Specification - Predicates — Confirms the correct syntax for using predicates with child elements, e.g., para[title="Introduction"] to filter based on child element content.

→ Workday Pro Integrations Study Guide: XSLT Transformations for Workday Integrations — Details how to use XPath predicates in XSLT to filter education groups based on element values like wd:Degree.

Explanation:

This question tests the security activation step required after configuring an Integration System User (ISU), Integration System Security Group (ISSG), and their related security policies. Even when the correct security is configured and assigned to an EIB, pending security policy changes must be activated before the integration can run successfully.

🟢 Correct Option:

A. Activate Pending Security Policy Changes
After configuring security policies for the ISU and ISSG, Workday keeps those changes in a pending state until they are activated. Running Activate Pending Security Policy Changes applies the updated permissions to the tenant. This activation is required before launching the EIB so that the integration runs with the newly configured security settings and access permissions.

🔴 Incorrect options:

B. View Security for Securable Item
This task is used to review security information associated with a securable item. It helps administrators understand which security groups or policies have access, but it does not activate pending security changes. Therefore, viewing security alone will not make the EIB ready to launch.

C. Assign the ISSG to only one security policy
An ISSG may be associated with the security policies required for its integration access. There is no general requirement that an ISSG be assigned to only one security policy before launching an EIB. The critical step is activating the pending security policy changes.

D. Maintain Integration Security Policies
This task is used to configure or maintain integration security policies. However, configuring the policies does not automatically apply pending changes. Once the required policies have been configured, the pending changes must be activated before the EIB can use the updated security configuration.

🔧 Reference:
→ Workday Integration Security Documentation — Official Workday Community documentation covering integration security configuration and activation of security policy changes.

Explanation:

This question tests your knowledge of change detection parameters in Workday Core Connectors. It evaluates whether you understand how "As of Entry Moment" and "Effective Date" work together to extract transaction updates.

✅ Correct Option:

Option C:
Option C is correct because the change was entered on May 13, 2024, with an effective date of April 30, 2024. In Run #1, the entry window (May 1 to May 15) and effective date window (April 30 to May 15) capture this update.

❌ Incorrect options:

Option A:
Option A is incorrect because Core Connectors utilize delta tracking, meaning once a transaction is successfully processed in Run #1, it will not be re-extracted in Run #2.

Option B:
Option B is incorrect because the entry moment (May 13) falls before the last successful entry moment of Run #2 (May 15), so Run #2 misses the change.

Option D:
Option D is incorrect because the transaction falls within the parameter windows of Run #1, ensuring that the compensation change is captured rather than completely excluded.

🔧 Reference:
→ Workday Community Core Connectors Guide confirms that change detection filters transactions using entry moment and effective date ranges to avoid duplicate processing.