Workday Pro Integrations Certification Practice Tests

Prévia do material em texto

Download Valid Workday Pro Integrations PDF Questions with Answers to Study
1 / 21
Exam : Workday Pro
Integrations
Title :
https://www.passcert.com/Workday-Pro-Integrations.html
Workday Pro Integrations
Certification Exam
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
2 / 21
1.You have been asked to refine a report which outputs one row per worker and is being used in an
integration that sends worker data to one of your third-party systems. The integration should only send
workers who have been hired in the last 30 days.
Where in the custom report definition can you specify a condition that would include only workers who
have been hired in the last 30 days?
A. Subfilter
B. Output
C. Columns
D. Filter
Answer: D
Explanation:
In Workday, when refining a custom report to include specific conditions such as limiting the output to
workers hired in the last 30 days, the appropriate place to specify this condition is within the Filter tab of
the custom report definition. The Filter tab allows you to define criteria that determine which instances of
the primary business object (in this case, "Worker") are included in the report output.
This is critical for integrations, as the filtered data ensures that only relevant records are sent to the
third-party system.
The requirement here is to restrict the report to workers hired within the last 30 days. In Workday reporting,
this can be achieved by adding a filter condition on the "Hire Date" field of the Worker business object.
Specifically, you would configure the filter to compare the "Hire Date" against a dynamic date range, such
as "Current Date minus 30 days" to "Current Date." This ensures the report dynamically adjusts to include
only workers hired in the last 30 days each time it runs, which aligns with the needs of an integration
sending real-time data to a third-party system.
Here’s why the other options are incorrect:
A. Subfilter: Subfilters in Workday are used to further refine data within a related business object or a
subset of data already filtered by the primary filter. They are not the primary mechanism for applying a
condition to the main dataset (e.g., all workers). For this scenario, a subfilter would be unnecessary since
the condition applies directly to the Worker business object, not a related object.
B. Output: The Output section of a custom report definition controls how the report is displayed or
delivered (e.g., file format, scheduling), not the data selection criteria. It does not allow for specifying
conditions like hire date ranges.
C. Columns: The Columns tab defines which fields are displayed in the report output (e.g., Worker ID,
Name, Hire Date). While you can add the "Hire Date" field here for visibility, it does not control which
workers are included in the report—that is the role of the Filter tab.
To implement this in practice:
In the custom report definition, go to the Filter tab.
Add a new filter condition.
Select the "Hire Date" field from the Worker business object.
Set the operator to "in the range" and define the range as "Current Date - 30 days" to "Current Date"
(using dynamic date functions available in Workday).
Save and test the report to ensure it returns only workers hired within the last 30 days.
This filtered report can then be enabled as a web service (via the Advanced tab) or used in an Enterprise
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
3 / 21
Interface Builder (EIB) or Workday Studio integration to send the data to the third-party system, meeting
the integration requirement.
Reference from Workday Pro Integrations Study Guide:
Workday Report Writer Fundamentals: Section on "Creating and Managing Filters" explains how filters
are used to limit report data based on specific conditions, such as date ranges.
Integration System Fundamentals: Discusses how custom reports serve as data sources for integrations
and the importance of filters in defining the dataset.
Core Connectors & Document Transformation: Highlights the use of filtered custom reports in outbound
integrations to third-party systems.
2.You need to create a report that includes data from multiple business objects. For a supervisory
organization specified at run time, the report must output one row per worker, their active benefit plans,
and the names and ages of all related dependents. The Worker business object contains the Employee,
Benefit Plans, and Dependents fields. The Dependent business object contains the employee's
dependent's Name and Age fields.
How would you select the primary business object (PBO) and related business objects (RBO) for the
report?
A. PBO: Dependent, RBO: Worker
B. PBO: Worker, RBO: Dependent
C. PBO: Dependent, no RBOs
D. PBO: Worker; no RBOs
Answer: B
Explanation:
In Workday reporting, selecting the appropriate Primary Business Object (PBO) and Related Business
Objects (RBOs) is critical to ensure that the report retrieves and organizes data correctly based on the
requirements. The requirement here is to create a report that outputs one row per worker for a specified
supervisory organization, including their active benefit plans and the names and ages of all related
dependents. The Worker business object contains fields like Employee, Benefit Plans, and Dependents,
while the Dependent business object provides the Name and Age fields for dependents.
Why Worker as the PBO?The report needs to output "one row per worker," making the Worker business
object the natural choice for the PBO. In Workday, the PBO defines the primary dataset and determines
the granularity of the report (i.e., one row per instance of the PBO). Since the report revolves around
workers and their associated data (benefit plans and dependents), Worker is the starting point.
Additionally, the requirement specifies a supervisory organization at runtime, which is a filter applied to
the Worker business object to limit the population.
Why Dependent as an RBO?The Worker business object includes a "Dependents" field, which is a
multi-instance field linking to the Dependent business object. To access detailed dependent data (Name
and Age), the Dependent business object must be added as an RBO. This allows the report to pull in the
related dependent information for each worker. Without the Dependent RBO, the report could only
reference the existence of dependents, not their specific attributes like Name and Age.
Analysis of Benefit Plans: The Worker business object already contains the "Benefit Plans" field, which
provides access to active benefit plan data. Since this is a field directly available on the PBO (Worker), no
additional RBO is needed to retrieve benefit plan information.
Option Analysis:
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
4 / 21
A. PBO: Dependent, RBO: Worker: Incorrect. If Dependent were the PBO, the report would output one
row per dependent, not one row per worker, which contradicts the requirement. Additionally, Worker as an
RBO would unnecessarily complicate accessing worker-level data.
B. PBO: Worker, RBO: Dependent: Correct. This aligns with the requirement: Worker as the PBO ensures
one row per worker, and Dependent as the RBO provides access to dependent details (Name and Age).
Benefit Plans are already accessible via the Worker PBO.
C. PBO: Dependent, no RBOs: Incorrect. This would result in one row per dependent and would not allow
easy access to worker or benefit plan data, failing to meet the "one row per worker" requirement.
D. PBO: Worker, no RBOs: Incorrect. While Worker as the PBO is appropriate, omitting the Dependent
RBO prevents the report from retrieving dependent Name and Age fields, which are stored in the
Dependent business object, not directly on Worker.
Implementation:
Create a custom report with Worker as the PBO.
Add a filter for the supervisory organization (specified at runtime) on the Worker PBO.
Add Dependent as an RBO to access Name and Age fields.
Include columns from Worker (e.g., Employee,Benefit Plans) and Dependent (e.g., Name, Age).
Reference from Workday Pro Integrations Study Guide:
Workday Report Writer Fundamentals: Section on "Selecting Primary and Related Business Objects"
explains how the PBO determines the report’s row structure and RBOs extend data access to related
objects.
Integration System Fundamentals: Discusses how multi-instance fields (e.g., Dependents on Worker)
require RBOs to retrieve detailed attributes.
3.You have a population of workers who have put multiple names in their Legal Name - First Name
Workday delivered field. Your third-party vendor only accepts one-word first names. For workers that have
included a middle name, the first and middle names are separated by a single space.
You have been asked to implement the following logic:
* Extract the value before the single space from the Legal Name - First Name Workday delivered field.
* Count the number of characters in the extracted value.
* Identify if the number of characters is greater than.
* If the count of characters is greater than 0, use the extracted value. Otherwise, use the Legal Name -
First Name Workday delivered field.
What functions are needed to achieve the end goal?
A. Extract Single Instance, Text Length, Numeric Constant, True/False Condition
B. Text Constant, Substring Text, Arithmetic Calculation, Evaluate Expression
C. Format Text, Convert Text to Number, True/False Condition, Evaluate Expression
D. Substring Text, Text Length, True/False Condition, Evaluate Expression
Answer: D
Explanation:
The task involves processing the "Legal Name - First Name" field in Workday to meet a third-party
vendor’s requirement of accepting only one-word first names.
For workers with multiple names (e.g., "John Paul"), separated by a single space, the logic must:
Extract the value before the space (e.g., "John" from "John Paul").
Count the characters in the extracted value.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
5 / 21
Check if the character count is greater than 0.
Use the extracted value if the count is greater than 0; otherwise, use the original "Legal Name - First
Name" field.
This logic is typically implemented in Workday using calculated fields within a custom report or integration
(e.g., EIB or Studio).
Let’s break down the required functions:
Substring Text: This function is needed to extract the portion of the "Legal Name - First Name" field before
the space. In Workday, the Substring Text function allows you to specify a starting position (e.g., 1) and
extract text up to a delimiter (e.g., a space).
For example, Substring Text ("John Paul", 1, Index of " ") would return "John."
Text Length: After extracting the substring (e.g., "John"), the logic requires counting its characters to
ensure it’s valid. The Text Length function returns the number of characters in a text string (e.g., Text
Length("John") True/False Condition: The logic involves a conditional check: "Is the number of characters
greater than 0?" The True/False Condition function evaluates this (e.g., Text Length(extracted value) > 0),
returning True if the extracted value exists and False if it’s empty (e.g., if no space exists or extraction
fails).
Evaluate Expression: This function implements the if-then-else logic: if the character count is greater than
0, use the extracted value (e.g., "John"); otherwise, use the original "Legal Name - First Name" field (e.g.,
"John Paul"). Evaluate Expression combines the True/False Condition with the output values.
Option Analysis:
A. Extract Single Instance, Text Length, Numeric Constant, True/False Condition: Incorrect. Extract Single
Instance is used for multi-instance fields (e.g., selecting one dependent), not text parsing. Numeric
Constant isn’t needed here, as no fixed number is involved.
B. Text Constant, Substring Text, Arithmetic Calculation, Evaluate Expression: Incorrect. Text Constant
provides a fixed string (e.g., "abc"), not dynamic extraction. Arithmetic Calculation isn’t required, as this is
a text length check, not a numeric operation beyond comparison.
C. Format Text, Convert Text to Number, True/False Condition, Evaluate Expression: Incorrect. Format
Text adjusts text appearance (e.g., capitalization), not extraction. Convert Text to Number isn’t needed, as
Text Length already returns a number.
D. Substring Text, Text Length, True/False Condition, Evaluate Expression: Correct. These functions align
perfectly with the requirements: extract the first name, count its length, check the condition, and choose
the output.
Implementation:
Create a calculated field using Substring Text to extract text before the space.
Use Text Length to count characters in the extracted value.
Use True/False Condition to check if the length > 0.
Use Evaluate Expression to return the extracted value or the original field based on the condition.
Reference from Workday Pro Integrations Study Guide:
Workday Calculated Fields: Section on "Text Functions" details Substring Text and Text Length usage.
Integration System Fundamentals: Explains how calculated fields with conditions (True/False, Evaluate
Expression) transform data for third-party systems.
Core Connectors & Document Transformation: Highlights text manipulation for outbound integration
requirements.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
6 / 21
4.Your manager has asked for a value on their dashboard for how many days away the birthdays are of
their direct reports. The format of the output should be [Worker's Name]'s birthday is in [X] days, where
you must calculate the number of days until a Worker's next birthday. An example output is "Logan
McNeil's birthday is in 103 days."
Which calculated field functions do you need to accomplish this?
A. Format Date, Increment or Decrement Date, Extract Single Instance, Format Text
B. Build Date, Format Date, Extract Single Instance, Format Text
C. Date Difference, Format Number, Text Constant, Concatenate Text
D. Increment or Decrement Date, Format Number, Text Constant, Concatenate Text
Answer: C
Explanation:
The requirement is to create a calculated field for a dashboard that displays a worker’s name and the
number of days until their next birthday in the format "[Worker's Name]'s birthday is in [X] days" (e.g.,
"Logan McNeil's birthday is in 103 days"). This involves calculating the difference between today’s date
and the worker’s next birthday, then formatting the output as a text string.
Let’s break down the necessary functions:
Date Difference: To calculate the number of days until the worker’s next birthday, you need to determine
the difference between the current date and the worker’s birthdate in the current or next year (whichever
is upcoming). The Date Difference function calculates the number of days between two dates.
In this case:
Use the worker’s "Date of Birth" field (from the Worker business object).
Adjust the year of the birthdate to the current year or next year (if the birthday has already passed this
year) using additional logic.
Calculate the difference from today’s date to this adjusted birthday date.
For example, if today is February 21, 2025, and Logan’s birthday is June 4 (adjusted to June 4, 2025),
Date Difference returns 103 days.
Format Number: The result of Date Difference is a numeric value (e.g., 103). To ensure it displays cleanly
in the output string (without decimals or unnecessary formatting), Format Number can be used to convert
it to a simple integer string (e.g., "103").
Text Constant: To build the output string, static text like "’s birthday is in " and " days" is needed. The Text
Constant function provides fixed text values to include in the final concatenated result.
Concatenate Text: The final step is to combine the worker’s name (e.g., "Logan McNeil"), the static text,
and the calculated days into one string. Concatenate Text merges multiple text values into a single output,
such as "Logan McNeil" + "’s birthday is in " + "103" + " days".
Option Analysis:
A. Format Date,Increment or Decrement Date, Extract Single Instance, Format Text: Incorrect.
Format Date converts dates to strings but doesn’t calculate differences. Increment or Decrement Date
adjusts dates but isn’t suited for finding days until a future event. Extract Single Instance is for
multi-instance fields, not relevant here. Format Text adjusts text appearance, not numeric calculations.
B. Build Date, Format Date, Extract Single Instance, Format Text: Incorrect. Build Date creates a date
from components, useful for setting the next birthday, but lacks the difference calculation. Format Date
and Extract Single Instance don’t apply to the core need.
C. Date Difference, Format Number, Text Constant, Concatenate Text: Correct. These functions cover
calculating the days, formatting the number, adding static text, and building the final string.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
7 / 21
D. Increment or Decrement Date, Format Number, Text Constant, Concatenate Text: Incorrect. Increment
or Decrement Date can’t directly calculate days to a future birthday without additional complexity; Date
Difference is more appropriate.
Implementation:
Use Date Difference to calculate days from today to the next birthday (adjusting the year dynamically with
additional logic if needed).
Apply Format Number to ensure the result is a clean integer.
Use Text Constant for static text ("’s birthday is in " and " days").
Use Concatenate Text to combine Worker Name, static text, and the formatted number.
Reference from Workday Pro Integrations Study Guide:
Workday Calculated Fields: Section on "Date Functions" explains Date Difference for calculating time
spans.
Report Writer Fundamentals: Covers Concatenate Text and Text Constant for string building in reports.
5.You need to filter a custom report to only show workers that have been terminated after a
user-prompted date.
How do you combine conditions in the filter to meet this requirement?
A. Worker Status is equal to the value "Terminated" OR Termination Date is greater than a value retrieved
from a prompt
B. Worker Status is equal to the value retrieved from a prompt AND Termination Date is less than a value
retrieved from a prompt.
C. Worker Status is equal to the value retrieved from a prompt OR Termination Date is equal to a value
retrieved from a prompt.
D. Worker Status is equal to the value "Terminated" AND Termination Date is greater than a value
retrieved from a prompt.
Answer: D
Explanation:
The requirement is to filter a custom report to show only workers terminated after a user-prompted date.
In Workday, filters are defined in the Filter tab of the custom report definition, and conditions can be
combined using AND/OR logic to refine the dataset.
Let’s analyze the requirement and options:
Key Conditions:
Workers must be terminated, so the "Worker Status" field must equal "Terminated."
The termination must occur after a user-specified date, so the "Termination Date" must be greater than
the prompted value.
Both conditions must be true for a worker to appear in the report, requiring an AND combination.
Option Analysis:
A. Worker Status is equal to the value "Terminated" OR Termination Date is greater than a value retrieved
from a prompt: Incorrect. Using OR means the report would include workers who are terminated
(regardless of date) OR workers with a termination date after the prompt (even if not terminated), which
doesn’t meet the strict requirement of terminated workers after a specific date.
B. Worker Status is equal to the value retrieved from a prompt AND Termination Date is less than a value
retrieved from a prompt: Incorrect. Worker Status shouldn’t be a prompted value (it’s fixed as
"Terminated"), and "less than" would show terminations before the date, not after.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
8 / 21
C. Worker Status is equal to the value retrieved from a prompt OR Termination Date is equal to a value
retrieved from a prompt: Incorrect. Worker Status shouldn’t be prompted, and "equal to" limits the filter to
exact matches, not "after" the date. OR logic also broadens the scope incorrectly.
D. Worker Status is equal to the value "Terminated" AND Termination Date is greater than a value
retrieved from a prompt: Correct. This ensures workers are terminated (fixed value) AND their termination
date is after the user-entered date, precisely meeting the requirement.
Implementation:
In the custom report’s Filter tab, add two conditions:
Field: Worker Status, Operator: equals, Value: "Terminated".
Field: Termination Date, Operator: greater than, Value: Prompt for Date (configured as a report prompt).
Set the logical operator between conditions to AND.
Test with a sample date to verify only terminated workers after that date appear.
Reference from Workday Pro Integrations Study Guide:
Workday Report Writer Fundamentals: Section on "Creating and Managing Filters" details combining
conditions with AND/OR logic and using prompts.
Integration System Fundamentals: Notes how filtered reports support integration data sources with
dynamic user inputs.
6.Refer to the following scenario to answer the question below.
You need to configure a Core Connector: Candidate Outbound integration for your vendor. The connector
requires the data initialization service (DIS).
The vendor needs a value on the output file which contains the average number of jobs a candidate
applied to. This value is not delivered by Workday so you have identified that you will need to build a
calculated field to generate this value.
What steps do you follow to output the calculated field?
A. Configure a custom field override service to output the calculation.
B. Configure integration attributes to output the calculation.
C. Configure integration field attributes to output the calculation.
D. Configure integration field overrides to output the calculation.
Answer: D
Explanation:
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
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
9 / 21
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 isthe 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.
Reference 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.
7.Refer to the following scenario to answer the question below.
You need to configure a Core Connector: Candidate Outbound integration for your vendor. The connector
requires the data initialization service (DIS).
The vendor needs the file to only include candidates that undergo a candidate assessment event in
Workday.
How do you accomplish this?
A. Configure the integration services to only include candidates with assessments.
B. Set the integration transaction log to subscribe to specific transaction types.
C. Make the Candidate Assessment field required in integration field attributes.
D. Create an integration map to output values for candidates with assessments.
Answer: A
Explanation:
The scenario requires configuring a Core Connector: Candidate Outbound integration with the Data
Initialization Service (DIS) to include only candidates who have undergone a candidate assessment event
in Workday. Core Connectors are event-driven integrations that rely on business process transactions or
specific data changes to trigger data extraction.
Let’s analyze how to meet this requirement:
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
10 / 21
Understanding Core Connector and DIS: The Core Connector: Candidate Outbound integration extracts
candidate data based on predefined services and events. The Data Initialization Service (DIS) ensures
the initial dataset is populated, but ongoing updates depend on configured integration services that define
which candidates to include based on specific events or conditions.
Candidate Assessment Event: In Workday, a "candidate assessment event" typically refers to a step in
the recruiting business process where a candidate completes an assessment. The requirement to filter for
candidates with this event suggests limiting the dataset to those who triggered an assessment-related
transaction.
Integration Services: In Core Connectors, integration services determine the scope of data extracted by
subscribing to specific business events or conditions. For this scenario, you can configure the integration
services to monitor the "Candidate Assessment" event (or a related business process step) and include
only candidates who have completed it. This is done by selecting or customizing the appropriate service
within the Core Connector configuration to filter the candidate population.
Option Analysis:
A. Configure the integration services to only include candidates with assessments: Correct. This involves
adjusting the integration services in the Core Connector to filter candidates based on the assessment
event, ensuring only relevant candidates are included in the output file.
B. Set the integration transaction log to subscribe to specific transaction types: Incorrect. The integration
transaction log tracks processed transactions for auditing but doesn’t control which candidates are
included in the output. Subscription to events is handled via integration services, not the log.
C. Make the Candidate Assessment field required in integration field attributes: Incorrect.
Integration field attributes define field-level properties (e.g., formatting or mapping), not the population of
candidates included. Making a field "required" doesn’t filter the dataset.
D. Create an integration map to output values for candidates with assessments: Incorrect. Integration
maps transform or map field values (e.g., converting "United States" to "USA") but don’t filter the
population of candidates included in the extract. Filtering is a service-level configuration.
Implementation:
Edit the Core Connector: Candidate Outbound integration.
In the Integration Services section, select or configure a service tied to the "Candidate Assessment" event
(e.g., a business process completion event).
Ensure the service filters the candidate population to those with an assessment event recorded. Test the
integration to verify only candidates with assessments are extracted.
Reference from Workday Pro Integrations Study Guide:
Core Connectors & Document Transformation: Section on "Configuring Integration Services" explains
how services define the data scope based on events or conditions.
Integration System Fundamentals
8.Refer to the following scenario to answer the question below.
You need to configure a Core Connector: Candidate Outbound integration for your vendor. The connector
requires the data initialization service (DIS).
The vendor requests additional formatting of the candidate Country field.
For example, if a candidate's country is the United States of America, the output should show USA.
What steps do you follow to meet this request?
A. Use an Evaluated Expression calculation and add it to the integration's report data source.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
11 / 21
B. Use the integration related action Configure Integration Population Eligibility.
C. Use the integration services to only output shortened country codes.
D. Use the integration related action Configure Integration Maps.
Answer: D
Explanation:
The scenario involves a Core Connector: Candidate Outbound integration with the Data Initialization
Service (DIS), where the vendor requires the "Country" field to be formatted differently (e.g., "United
States of America" to "USA"). This is a data transformation requirement, and Core Connectors provide
specific tools to handle such formatting.
Let’s evaluate the solution:
Requirement: The vendor needs a shortened country code (e.g., "USA" instead of "United States of
America") in the output file. This involves transforming the delivered "Country" field value from the
Candidate business object into a vendor-specific format.
Integration Maps: In Workday Core Connectors, integration maps are used to transform or map field
values from Workday’s format to a vendor’s required format.
For example, you can create a map that replaces "United States of America" with "USA," "Canada" with
"CAN," etc. This is configured via the "Configure Integration Maps" related action on the integration
system, allowing you to define a lookup table or rule-based transformation for the Country field.
Option Analysis:
A. Use an Evaluated Expression calculation and add it to the integration’s report data source: Incorrect.
While an Evaluate Expression calculated field could transform the value (e.g., if-then logic), Core
Connectors don’t directly use report data sources for output formatting. Calculated fields are better suited
for custom reports or EIBs, not Core Connector field mapping.
B. Use the integration related action Configure Integration Population Eligibility: Incorrect. This action
filters the population of candidates included (e.g., based on eligibility criteria), not the formatting of
individual fields like Country.
C. Use the integration services to only output shortened country codes: Incorrect. Integration services
define the dataset or events triggering the integration, not field-level formatting or transformations.
D. Use the integration related action Configure Integration Maps: Correct. Integration maps are the
standard Core Connector tool for transforming field values (e.g.,mapping "United States of America" to
"USA") to meet vendor requirements.
Implementation:
Navigate to the Core Connector: Candidate Outbound integration system.
Use the related action Configure Integration Maps.
Create a new map for the "Country" field (e.g., Source Value: "United States of America," Target
Value: "USA").
Apply the map to the Country field in the integration output.
Test the output file to ensure the transformed value (e.g., "USA") appears correctly.
Reference from Workday Pro Integrations Study Guide:
Core Connectors & Document Transformation: Section on "Configuring Integration Maps" details how to
transform field values for vendor-specific formatting.
Integration System Fundamentals: Explains how Core Connectors handle data transformation through
maps rather than calculated fields or services for field-level changes.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
12 / 21
9.Refer to the following scenario to answer the question below.
You have been asked to build an integration using the Core Connector: Worker template and should
leverage the Data Initialization Service (DIS). The integration will be used to export a full file (no change
detection) for employees only and will include personal dat a. The vendor receiving the file requires
marital status values to be sent using a list of codes that they have provided instead of the text values that
Workday uses internally and if a text value in Workday does not align with the vendors list of codes the
integration should report "OTHER".
What configuration is required to output the list of codes required from by the vendor instead of Workday's
values in this integration?
A. Configure Integration Maps with a blank Default
B. Configure Integration Attributes with a blank Default
C. Configure Integration Maps with "OTHER" as a Default
D. Configure Integration Attributes with "OTHER" as a Default
Answer: C
Explanation:
The scenario involves a Core Connector: Worker integration using the Data Initialization Service (DIS) to
export a full file of employee personal data.
The vendor requires marital status values to be transformed from Workday’s internal text values (e.g.,
"Married," "Single") to a specific list of codes (e.g., "M," "S"), and any Workday value not matching the
vendor’s list should output "OTHER." Let’s analyze the configuration:
Requirement: Transform the "Marital Status" field values into vendor-specific codes, with a fallback to
"OTHER" for unmapped values. This is a field-level transformation, common in Core Connectors when
aligning Workday data with external system requirements.
Integration Maps: In Core Connectors, Integration Maps are the primary tool for transforming field values.
You create a map that defines source values (Workday’s marital status text) and target values (vendor’s
codes). The "Default" setting in an integration map specifies what value to output if a Workday value isn’t
explicitly mapped. Here, setting the default to "OTHER" ensures that any marital status not in the vendor’s
list (e.g., a new Workday value like "Civil Union" not recognized by the vendor) is output as "OTHER."
Option Analysis:
A. Configure Integration Maps with a blank Default: Incorrect. A blank default would leave the field empty
or pass the original Workday value for unmapped cases, not "OTHER," failing the requirement.
B. Configure Integration Attributes with a blank Default: Incorrect. Integration Attributes define
integration-level settings (e.g., file name, delivery method), not field value transformations. They don’t
support mapping or defaults for specific fields like marital status.
C. Configure Integration Maps with "OTHER" as a Default: Correct. This uses Integration Maps to map
Workday values to vendor codes and sets "OTHER" as the default for unmapped values, meeting the
requirement fully.
D. Configure Integration Attributes with "OTHER" as a Default: Incorrect. Integration Attributes don’t
handle field-level transformations or defaults for data values, making this option inapplicable.
Implementation:
Edit the Core Connector: Worker integration.
Use the related action Configure Integration Maps.
Create a map for the "Marital Status" field (e.g., "Married" → "M," "Single" → "S").
Set the Default Value to "OTHER" in the map configuration.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
13 / 21
Test the output to ensure mapped values use vendor codes and unmapped values return "OTHER."
Reference from Workday Pro Integrations Study Guide:
Core Connectors & Document Transformation: Section on "Configuring Integration Maps" explains
mapping field values and using defaults for unmapped cases.
Integration System Fundamentals: Highlights how Core Connectors transform data to meet vendor
specifications.
10.Refer to the following scenario to answer the question below.
You have been asked to build an integration using the Core Connector: Worker template and should
leverage the Data Initialization Service (DIS). The integration will be used to export a full file (no change
detection) for employees only and will include personal data.
What configuration is required to ensure that when outputting phone number only the home phone
number is included in the output?
A. Configure an integration map to map the phone type.
B. Include the phone type integration field attribute.
C. Configure the phone type integration attribute.
D. Configure an integration field override to include phone type.
Answer: B
Explanation:
The scenario involves a Core Connector: Worker integration using DIS to export a full file of employee
personal data, with the requirement to output only the home phone number when including phone data.
Workday’s "Phone Number" field is multi-instance, meaning a worker can have multiple phone types (e.g.,
Home, Work, Mobile).
Let’s determine the configuration:
Requirement: Filter the multi-instance "Phone Number" field to include only the "Home" phone number in
the output file. This involves specifying which instance of the phone data to extract.
Integration Field Attributes: In Core Connectors, Integration Field Attributes allow you to refine how
multi-instance fields are handled in the output. For the "Phone Number" field, you can set an attribute like
"Phone Type" to "Home" to ensure only home phone numbers are included. This is a field-level
configuration that filters instances without requiring a calculated field or override.
Option Analysis:
A. Configure an integration map to map the phone type: Incorrect. Integration Maps transform field values
(e.g., "United States" to "USA"), not filter multi-instance data like selecting a specific phone type.
B. Include the phone type integration field attribute: Correct. This configures the "Phone Number" field to
output only instances where the phone type is "Home," directly meeting the requirement.
C. Configure the phone type integration attribute: Incorrect. "Integration attribute" refers to
integration-level settings (e.g., file format), not field-specific configurations. The correct term is
"integration field attribute."
D. Configure an integration field override to include phone type: Incorrect. Integration Field Overrides are
used to replace a field’s value with a calculated field or custom value, not to filter multi-instance data like
phone type.
Implementation:
Edit the Core Connector: Worker integration.
Navigate to the Integration Field Attributes section for the "Phone Number" field.
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
14 / 21
Set the "Phone Type" attribute to "Home" (or equivalent reference ID for Home phone).
Test the output file to confirm only home phone numbers are included.
Reference from Workday Pro Integrations Study Guide:
Core Connectors & Document Transformation: Section on "Integration Field Attributes" explains filtering
multi-instance fields like phone numbers by type.
Integration System Fundamentals: Notes how Core Connectors handle multi-instancedata with field-level
attributes.
11.Refer to the following scenario to answer the question below.
You have been asked to build an integration using the Core Connector: Worker template and should
leverage the Data Initialization Service (DIS). The integration will be used to export a full file (no change
detection) for employees only and will include personal data.
What configuration is required to ensure that only employees, and not contingent workers, are output by
this integration?
A. Configure the Integration Population Eligibility.
B. Configure a map for worker type in the Integration Maps.
C. Configure worker type in the Integration Field Attributes.
D. Configure eligibility in the Integration Field Overrides.
Answer: A
Explanation:
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").
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
15 / 21
Save and test to ensure only employee data is exported.
Reference 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.
12.Refer to the following scenario to answer the question below.
You have been asked to build an integration using the Core Connector: Worker template and should
leverage the Data Initialization Service (DIS). The integration will be used to export a full file (no change
detection) for employees only and will include personal data.
What configuration is required to output the value of a calculated field which you created for inclusion in
this integration?
A. Configure Integration Field Attributes.
B. Configure Integration Field Overrides.
C. Configure Integration Attributes.
D. Configure Integration Maps.
Answer: B
Explanation:
The scenario involves a Core Connector: Worker integration using the Data Initialization Service (DIS) to
export a full file of employee personal data, with a requirement to include a calculated field in the output.
Core Connectors rely on predefined field mappings, but custom calculated fields need specific
configuration to be included.
Let’s analyze the solution:
Requirement: Output the value of a calculated field created for this integration. In Workday, calculated
fields are custom-built (e.g., using Report Writer or Calculated Fields) and not part of the standard Core
Connector template, so they must be explicitly added to the output.
Integration Field Overrides: In Core Connectors, Integration Field Overrides allow you to replace a
delivered field’s value or add a new field to the output by mapping it to a calculated field. This is the
standard method to include custom calculated fields in the integration file. You create the calculated field
separately, then use overrides to specify where its value appears in the output structure (e.g., as a new
column or replacing an existing field).
Option Analysis:
A. Configure Integration Field Attributes: Incorrect. Integration Field Attributes refine how delivered fields
are output (e.g., filtering multi-instance data like phone type), but they don’t support adding or mapping
calculated fields.
B. Configure Integration Field Overrides: Correct. This configuration maps the calculated field to the
output, ensuring its value is included in the exported file.
C. Configure Integration Attributes: Incorrect. Integration Attributes define integration-level settings (e.g.,
file name, delivery protocol), not field-specific outputs like calculated fields.
D. Configure Integration Maps: Incorrect. Integration Maps transform existing field values (e.g., "Married"
to "M"), but they don’t add new fields or directly output calculated fields.
Implementation:
Create the calculated field in Workday (e.g., via Create Calculated Field task).
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
16 / 21
Edit the Core Connector: Worker integration.
Navigate to the Integration Field Overrides section.
Add a new override, selecting the calculated field and specifying its output position (e.g., a new field ID or
overriding an existing one).
Test the integration to confirm the calculated field value appears in the output file.
Reference from Workday Pro Integrations Study Guide:
Core Connectors & Document Transformation: Section on "Configuring Integration Field Overrides"
explains how to include calculated fields in Core Connector outputs.
Integration System Fundamentals: Notes the use of overrides for custom data in predefined integration
templates.
13.Refer to the following scenario to answer the question below.
You have configured a Core Connector: Worker integration, which utilizes the following basic
configuration:
• Integration field attributes are configured to output the Position Title and Business Title fields from the
Position Data section.
• Integration Population Eligibility uses the field Is Manager which returns true if the worker holds a
manager role.
• Transaction Log service has been configured to Subscribe to specific Transaction Types: Position Edit
Event.
You launch your integration with the following date launch parameters (Date format of
MM/DD/YYYY):
• 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
To test your integration, you made a change to a worker named Jeff Gordon who is not assigned to the
manager role. You perform an Edit Position on Jeff Gordon and update their business title to a new value.
Jeff Gordon's worker history shows the Edit Position Event as being successfully completed with an
effective date of 05/24/2024 and an Entry Moment of 05/24/2024 07:58:53 AM however Jeff Gordon does
not show up in your output.
What configuration element would have to be modified for the integration to include Jeff Gordon in the
output?
A. Transaction log subscription
B. Integration Population Eligibility
C. Date launch parameters
D. Integration Field Attributes
Answer: B
Explanation: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
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
17 / 21
Population Eligibility: Filters workers where "Is Manager" 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" Why Jeff is Excluded: The Integration Population Eligibility
restriction ("Is Manager" 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"
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" 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" Relaunch the integration and verify Jeff Gordon appears in the output.
Reference 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.
14.Refer to the following scenario to answer the question below.
You have configured a Core Connector: Worker integration, which utilizes the following basic
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
18 / 21
configuration:
• Integration field attributes are configured to output the Position Title and Business Title fields from the
Position Data section.
• Integration Population Eligibility uses the field Is Manager which returns true if the worker holds a
manager role.
• Transaction Log service has been configured to Subscribe to specific Transaction Types: Position Edit
Event.
You launch your integration with the following date launch parameters (Date format of MM/DD/YYYY):
• 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
To test your integration you made a change to a worker named Jared Ellis who is assigned to the
manager role for the IT Help Desk department. You perform an Edit Position on Jared and update the Job
Profile of the position to a new value. Jared Ellis' worker history shows the Edit Position Event as being
successfully completed with an effective date of 05/24/2024 and an Entry Moment of 05/24/2024 07:58:53
AM however Jared Ellis does not show up in your output.
What configuration element would have to be modified for the integration to include Jared Ellis in the
output?
A. Integration Population Eligibility
B. Integration Field Attributes
C. Date launch parameters
D. Transaction log subscription
Answer: C
Explanation:
The scenario describes a Core Connector: Worker integration configured to output specific fields (Position
Title and Business Title) for workers who meet the Integration Population Eligibility criteria (Is Manager In
Workday integrations, the Core Connector: Worker uses change detection mechanisms to identify and
process updates based on the Transaction Log and date launch parameters. The Transaction Log service
captures events such as the "Position Edit Event" and records them with an Effective Date (when the
change takes effect) and an Entry Moment (when the change was entered into the system).
The integration’s date launch parameters define the time window for which changes are retrieved:
As of Entry Moment: 05/25/2024 12:00:00 AM – This specifies the latest point in time for when changes
were entered into Workday.
Effective Date: 05/25/2024 – This defines the date for which the changes are effective.
Last Successful As of Entry Moment: 05/23/2024 12:00:00 AM – This indicates the starting point for entry
moments from the last successful run.
Last Successful Effective Date: 05/23/2024 – This indicates the starting point for effective dates from the
last successful run.
For an incremental run (like this one, since "Last Successful" parameters are provided), Workday
processes changes where the Entry Moment falls between the Last Successful As of Entry Moment
(05/23/2024 12:00:00 AM) and the As of Entry Moment (05/25/2024 12:00:00 AM), and where the
Effective Date falls between the Last Successful Effective Date (05/23/2024) and the Effective Date
(05/25/2024).
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
19 / 21
Now, let’s evaluate Jared Ellis’ edit:
Entry Moment: 05/24/2024 07:58:53 AM – This falls within the range of 05/23/2024 12:00:00 AM to
05/25/2024 12:00:00 AM.
Effective Date: 05/24/2024 – This falls within the range of 05/23/2024 to 05/25/2024.
At first glance, Jared’s edit seems to fit the date parameter window. However, the issue lies in the time
component of the date launch parameters. Workday interprets these parameters with precision down to
the second. The As of Entry Moment is set to 05/25/2024 12:00:00 AM (midnight), which is the very start
of May 25, 2024. Jared’s Entry Moment of 05/24/2024 07:58:53 AM is correctly within the range from
05/23/2024 12:00:00 AM to 05/25/2024 12:00:00 AM. However, the Transaction Log subscription to
"Position Edit Event" relies on the change being fully processed and available in the log by the time the
integration runs.
The integration might have run at a point where the effective date window or the subscription logic did not
correctly capture the event due to a mismatch in how the Effective Date is evaluated against the Last
Successful Effective Date. Specifically, if the integration only processes changes with an Effective Date
strictly after the Last Successful Effective Date (05/23/2024) up to the Effective Date (05/25/2024), and
the logic excludes changes effective exactly on 05/24/2024 due to a boundary condition or a timing issue
in the transaction log, Jared’s change might not be picked up.
To resolve this, modifying the Date launch parameters is necessary. Adjusting the As ofEntry Moment to a
later time (e.g., 05/25/2024 11:59:59 PM) or ensuring the Effective Date range explicitly includes all
changes effective on or after 05/23/2024 through 05/25/2024 would ensure Jared’s edit is captured. This
adjustment aligns the time window to include all relevant transactions logged before the integration run.
Let’s evaluate the other options:
A. Integration Population Eligibility: This is set to "Is Manager
B. Integration Field Attributes: These are configured to output Position Title and Business Title, and the
edit was to the Job Profile (part of Position Data). The fields are appropriately configured, so this is not the
issue.
D. Transaction Log Subscription: The subscription is set to "Position Edit Event," which matches Jared’s
edit. The subscription type is correct, so no change is needed here.
Thus, the issue stems from the date launch parameters not fully encompassing the timing of Jared’s edit
in the Transaction Log, making C. Date launch parameters the correct answer.
Workday Pro Integrations Study Guide Reference
Workday Integrations Study Guide: Core Connector: Worker – Section on "Change Detection Using
Transaction Log" explains how Transaction Log subscriptions filter events based on date parameters.
Workday Integrations Study Guide: Launch Parameters – Details the role of "As of Entry Moment" and
"Effective Date" in defining the scope of incremental runs.
Workday Integrations Study Guide: Incremental Processing – Describes how "Last Successful"
parameters establish the baseline for detecting changes in subsequent runs.
15.Refer to the following scenario to answer the question below.
You have configured a Core Connector: Worker integration, which utilizes the following basic
configuration:
• Integration field attributes are configured to output the Position Title and Business Title fields from the
Position Data section.
• Integration Population Eligibility uses the field Is Manager which returns true if the worker holds a
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
20 / 21
manager role.
• Transaction Log service has been configured to Subscribe to specific Transaction Types: Position Edit
Event.
You launch your integration with the following date launch parameters (Date format of
MM/DD/YYYY):
• 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
To test your integration, you made a change to a worker named Jared Ellis who is assigned to the
manager role for the IT Help Desk department. You use the Change Business Title related action on Jared
and update the Business Title of the position to a new value. Jared Ellis' worker history shows the Title
Change Event as being successfully completed with an effective date of 05/24/2024 and an Entry
Moment of 05/24/2024 07:58:53 AM however Jared Ellis does not show up in your output.
What configuration element would have to be modified for the integration to include Jared Ellis in the
output?
A. Transaction log subscription
B. Date launch parameters
C. Integration Field Attributes
D. Integration Population Eligibility
Answer: A
Explanation:
The scenario involves a Core Connector: Worker integration configured to output Position Title and
Business Title fields for workers who meet the Integration Population Eligibility criteria (Is Manager In
Workday, the Core Connector: Worker integration uses the Transaction Log service to detect changes
based on subscribed transaction types. The subscribed transaction type in this case is "Position Edit
Event," which is triggered when a position is edited via the "Edit Position" business process. However, the
test scenario involves a "Change Business Title" related action, which is a distinct business process in
Workday. This action updates the Business Title field but does not necessarily trigger a "Position Edit
Event." Instead, it generates a different event type, such as a "Title Change Event" (as noted in Jared’s
worker history), depending on how the system logs the action.
The date launch parameters provided are:
As of Entry Moment: 05/25/2024 12:00:00 AM – The latest point for entry moments.
Effective Date: 05/25/2024 – The latest effective date for changes.
Last Successful As of Entry Moment: 05/23/2024 12:00:00 AM – The starting point for entry moments
from the last run.
Last Successful Effective Date: 05/23/2024 – The starting point for effective dates from the last run.
Jared’s change has:
Entry Moment: 05/24/2024 07:58:53 AM – Falls between 05/23/2024 12:00:00 AM and 05/25/2024
12:00:00 AM.
Effective Date: 05/24/2024 – Falls between 05/23/2024 and 05/25/2024.
The date parameters correctly cover the time window of Jared’s change, meaning the issue is not with the
date range but with the event detection logic. The Transaction Log subscription determines which events
are processed by the integration. Since the subscription is set to "Position Edit Event" and the change
Download Valid Workday Pro Integrations PDF Questions with Answers to Study
21 / 21
was made via "Change Business Title" (logged as a "Title Change Event"), the integration does not
recognize this event because it is not subscribed to the appropriate transaction type.
To include Jared Ellis in the output, the Transaction Log subscription must be modified to include the
event type associated with the "Change Business Title" action, such as "Title Change Event" or a broader
category like "Position Related Event" that encompasses both position edits and title changes. This
ensures the integration captures the specific update made to Jared’s Business Title.
Let’s evaluate the other options:
B. Date launch parameters: The parameters already include Jared’s entry moment and effective date
within the specified ranges (05/23/2024 to 05/25/2024). Adjusting these would not address the mismatch
between the subscribed event type and the actual event triggered.
C. Integration Field Attributes: These are set to output Position Title and Business Title, and the change to
Business Title is within scope. The field configuration is correct and does not need modification.
D. Integration Population Eligibility: This is set to "Is Manager The root cause is the Transaction Log
subscription not aligning with the event type generated by the "Change Business Title" action, making
A. Transaction log subscription the correct answer.
Workday Pro Integrations Study Guide Reference
Workday Integrations Study Guide: Core Connector: Worker – Section on "Transaction Log
Configuration" explains how subscribing to specific transaction types filters the events processed by the
integration.
Workday Integrations Study Guide: Change Detection – Details how different business processes (e.g.,
Edit Position vs. Change Business Title) generate distinct event types in the Transaction Log.
Workday Integrations Study Guide: Event Subscription – Notes the importance of aligning subscription
types with the specific business actions being tested or monitored.