Ace Workday Integration Interviews: Top Scenarios Solved

However, in case you plan to go for interviews in Workday Integration Consultant or Workday Integration Architect positions, then there won't be any questions based on definition or syntax. However, what you would have to deal with is the large amount of scenario-based questions where it will require from you your understanding of trade-offs in architecture, failure scenarios, data synchronization of enterprise systems, and solving the business problems.

In order to successfully pass such interviews, along with demonstrating your knowledge of Workday integration architecture, i.e., EIB (Enterprise Interface Builder), Core Connectors, Document Transformation, Workday Studio, you will also need to demonstrate your knowledge of error handling, security, tuning of performance of systems, and coordination of systems.

Below are a few examples of workday integration interview questions. The scoring pattern for each question and the Workday Architecture required to answer the same is also mentioned.

The Dilemma of The Tools

Scenario

Interviewer: "I need an outbound integration which will transfer our worker data to an external downstream system. How are you going to choose between EIB, Core Connector and Workday Studio?"

Evaluation of the Problem and Purpose of the Solution

Here, you need to prove that you are capable of doing everything by yourself without any help of Workday Studio and will not make EIB to do anything which was not designed for this purpose. In other words, you should be aware of development overheads, maintenance, and native functionality.

Architecture of the Solution

You need to present your reasons for the selected solution taking into account four of them: complexity, transformation logic, requirements of the destination transport and volume.

In the first place, you have to keep in mind the principle of configuration rather than coding in Workday. As stated in any decent workday integration tutorial, in case the downstream system is capable of processing the standard file format such as CSV or XML, simple field filtering, standard scheduling, and there is no any business logic at all, you can use outbound EIB with Custom Report (Report as a Service).

When speaking about third party destination applications, namely payroll system, benefits insurance, and background checks, the necessity to assess the potentiality of using out-of-the-box Core Connector arises. Prebuilt Core Connectors that have pre-built schemas, changes tracking, and transaction logging are available. Core Connector, in combination with Document Transformation that uses XSLT technology for Workday's XML output transformation, allows conducting a massive amount of data transformation without developing custom Studio assembly.

The Workday Studio could be used only if the architectural approach requires something more than just EIBs and Connectors. Such approach will include the following situations:

• Big file processing in multithreading or splitting/aggregation modes for avoiding memory overflow.

• Transaction orchestration through several API endpoints, for instance, when information is taken from external vendor system, Workday Web Services are invoked, and then posted back to the third party.

• Custom error handling that involves alerts, routing, or database persistence.

• File transformations that cannot be done via Document Transformation.

Handling Large Amounts of Data and Memory Problems in Workday Studio

Scenario

"Inbound/Outbound integration in Workday Studio that deals with hundreds of thousands of records. At some point during the process execution, the execution fails due to out of memory exception or timeout. How would you fix it?"

The Problem & Assessment Objective

Workday is a multi-tenant cloud-based solution, meaning that all customers use one computing power and memory resources. There are restrictions on Workday in terms of execution time and memory usage by JVM. Moreover, it is about testing your knowledge of Workday architecture, namely the difference between stream processing and DOM processing in memory.

Approach to the Solution

First, it is needed to conduct the diagnosis. Check the logs of the Integration Events, analyze the timeline of the process execution and determine problems with data extraction (web service request), transformation (XSLT processing) or delivering the results.

If the problem is associated with memory starvation, explain how you would fix it by switching from in-memory processing to streaming processing in the Studio assembly:

• Splitter/Aggregator Design: Do not load whole XML file as DOM tree. Instead, cofigure the splitter to split the big XML file into smaller chunks. In the case of Workday Studio, use XPath or XML stream splitter to ensure that the whole payload is not loaded into heap memory.

• Transformation using XSLT: Bigger transformations are failing due to the usage of standard XSLT processor, where the tree traversal in memory takes place. It is required to ensure the usage of Streaming XSLT is happening or the record is split into small documents before the transformation of those documents takes place sequentially/batch-wise.

• Pagination for Web Services: Do not fetch all workers in a single API call while using Workday Web Services (Get_Workers). Instead of that, use the pagination parameters (Page and Count) and iterate through the workers' records fetching only one chunk of workers' record per iteration.

• Logging: Over-logging and/or attaching the payloads to an integration event uses huge memory space. Ensure that there is no excessive logging in Production environment. Use logging with summary information or only exceptions.

Delta and Change Detection Mechanism Design

Scenario

"There is a third party benefit provider who needs a delta file every day which should consist of only those employees who have gone through some kind of change in comparison with the last run. Could you explain your approach towards designing the delta mechanism and how will you make sure that no update is missed?"

Problem & Assessment Objective

The above mentioned scenario would help in testing your knowledge regarding the delta detection mechanism and specifically whether you are aware of the intricacies associated with the process such as the relation between transaction dating and integration failures.

Architecture Approach

You have to focus your response on the topic of transaction dating by Workday and transaction auditing.

If you implement Core Connectors then you should give explanation regarding the transaction logs used in the process. The transactions used in Core Connectors are for delta detection and include hires, terminations, changes to compensation and personal information. In the Core Connectors, there is an integration watermark which gets incremented only upon a successful integration run.

If you implement a solution using EIB or Custom Reports:

• Reporting Based on Effective Dates: Leverage Report-as-a-Service configuration based on effective date and entry date parameters. Pay special attention to the extremely significant difference between effective date and entry date: while the first one is about the moment in time of the occurrence of the event regarding its impact on the business, the second one (or the transaction date-time) refers to the time when the change has been registered in the system. For instance, if the HR administrator has backdated the raise in salary, which occurred two weeks ago on Tuesday, then you won’t find it with the help of effective date. You should rather use the entry date-time parameter.

• The Use of Watermarks in Integration Events: Create automation logic for capturing the timestamp of the last successful run. It is possible to achieve it by using Workday Studio and capturing the timestamp of the last successful Integration Event, which serves as the starting point for the current query in case there are no fatal errors during the current run.

• Full Refresh as Alternative Solution: Never forget to create an operational plan with the vendor in case they experience some difficulties.

Incoming Batch Update and Error Handling

Scenario

"You need to design an incoming integration to update compensation/personal information of your system using external human resource system. What if you get 20 invalid records out of 5 thousand records? How would you make sure the whole batch update doesn't fail and at the same time provide meaningful error messages to functional teams?"

Problem & Assessment Purpose

The data feeds mostly bring dirty data. You are being tested on your ability to design a fault tolerant integration which could filter out the invalid records, process only the valid records and at the same time provide meaningful error information to the functional team.

Architecture

Describe the architecture for a decoupled and transactional error handling solution.

First of all, talk about architectural design:

• ROW BY ROW VS BULK: The use of row by row or few number of batch size for moderate number of records through web services would enable updating of database with good data while skipping bad rows.

• Pre-Validation In Architecture: The pre-validation must be done before the web service invocation that is related to the business process called "Change Compensation". This includes mandatory fields, validation of Workday reference id (Organization Id/Job Profile Id) and effective date.

Now let us see the error handling process:

• Error Handling: In case there is any error in web service invocation, then the error is caught by the integration assembly and not raised to the master execution thread.

• Error Reporting: Create error log where SOAP error, record ID of the failed record and entered data will be logged.

• Post Execution Error Report: Create Post Execution error report in CSV file format or email alert notification. Post Execution error report will be generated as part of the Integration Event and will be forwarded to the Compensation/Payroll team.

• Process Robustness: In case the multi-step process is critical, there will be a requirement to store the record in the staging database or creating Workday Business Process Task, so that the failed records could get to the humans.

Web Service Authentication and Security

Scenario

"You need to integrate the middleware platform with Workday in order to start the process of integration and get access to the Workday payroll data. What security architecture would you design? What kind of authentication protocol would you choose? What measures would you take to ensure the least privilege principle?"

Problem & Solution Goal

Security requirements in enterprise human capital management are very high. You need to prove that you are going to implement safe procedures (creation of special Integration System Users instead of working through employees' accounts). Knowledge of the latest authentication protocols for enterprises is also important.

Solution

You have to build your response based on the following Workday security principles:

• Integration System Users (ISU): You have to prove that all integrations are going to be performed using not administrators' personal accounts but Integration System Users. That is necessary in order to ensure accountability in audit logs and service availability even after the departure from the company.

• Integration System Security Groups (ISSG): You have to add the created ISU to certain Integration System Security Group (either segmented or non-segmented):You cannot add ISU to such general security groups as System Auditor or HR Administrator.

• Security Policy for Domain and Business Process: Review fields by fields and actions by actions regarding the fields and actions needed for the integration. Grant permission to Get and/or Put on security policies of the domains and business process security policies which are required for the integration. After you have set your security policies, commit your pending security policy changes.

• Authentication Protocol: For enterprise integration purposes, the ideal protocol to use is OAuth 2.0 with JWT bearer grant and mutual TLS certificate-based authentication rather than username and password-based authentication. When using basic authentication, it is important to implement password expiration policy and IP address whitelisting so that access will only be via authorized corporate IPs.

Real-Time Integration Design and Webhooks Scenarios

Scenario

"Please let me know what needs to be done in case of the below scenario: 'When an employee is terminated, we need our third party IT access management system to revoke software license of the individual within two minutes.'"

Problem Statement and the Goal of Assessment

Daily batch event processing is not enough in case of security relevant events processing such as termination of employment. This problem will help you check your understanding of the event driven architecture and practice of implementing it in real-time integration with the help of Workday.

Architectural Solution

How do you set up the event-driven integration with the help of Workday Business Process Integration by means of outbound messaging?

How does it work:

• Business Process Integration Step: You open the Business Process definition of Termination and insert the Integration Step right after the last approval step or background step from the process chain.

• Integration Trigger: You configure this step to trigger the outbound integration when this event happens (it can be EIB or Workday Studio Integration). Workday will provide the event context (unique transaction ID of this termination event) within the integration payload.

• Data Retrieval: Since event context is provided, the integration retrieves the data about this particular employee only, and it happens in seconds.

• Another way is to provide the reasons for invoking an external API endpoint via an outbound REST call from Workday Studio or Workday Integration Message queues, which will allow sending the event notification to enterprise message brokers (Kafka, AWS SQS, etc.), broadcasting the message to all other revoking downstream IT systems.

• Resilience Strategy: Discuss that a real-time integration might experience outages of the network from external sources. In such a case, the integration should have a retry mechanism with exponential backoff, and in addition, a daily reconciliation batch job should be performed to ensure that all terminations have been processed even in the event of network outages.

Troubleshooting Silent Failures and Data Mismatch

Scenario

"You have successfully finished your integration run; however, your vendor reports that there are still missing hires in the file. What would you do in order to troubleshoot the issue?"

The Problem & Goal of Assessment

The most risky problems in enterprise integrations are those that do not lead to a failure of the system and errors. On the contrary, the problem emerges when some data is silently ignored by the system, but the run itself has been considered completed successfully.

Solutions

Ensure that the problem is accurately diagnosed:

• Verification of Effective Dates and Time Zones: The most common cause of non-inclusion of new employees in the database is related to the wrong effective dates. New employees typically have an effective date in the future since this is the date from which they will be employed. Therefore, when the integration process is designed to extract only employees whose employment occurs on the same date as today, those to be employed in the future will not be extracted. One needs to ensure that the integration process is designed in UTC and the real hiring was done in the regional time zone.

• Verification of Security Group Filters: Ensure that the Integration System User has access to all organizational, supervisory, and restricted security groups. If the missing new employees belong to the Executive Supervisory Organization or to a new subsidiary that uses a security group that is not part of the ISSG, then Workday filters them out without giving any error messages.

• Criteria of Report Eligibility Analysis: Perform an analysis on the Custom Report created during the process of integration in order to check whether any restrictive logic was put in place to limit the access to the Custom Report in question in terms of excluding some categories of employees/contingent employees or some Pay Groups from the report criteria, and so forth, and therefore not reflecting the information about the newly hired employees.

• Transaction Log and Reversed Transactions: Check for any reversing, correction, or hold of hire transactions in case the detection mechanism has been used.

• XML Raw Data: Collect the XML raw data within the Integration Event before its transformation. In case the information regarding the newly hired employees is included in the XML raw data, then the issue resides in the transformation process; otherwise, it is in the criteria of report eligibility or security.

Managing Environment Migrations and Multi-Tenant Lifecycle Management

Scenario

“You have developed complex integration systems in an Implementation or Sandbox tenant. How do you plan on migrating the integrations into Production? How will you ensure no configuration drifts and hardcoded dependency breaks?”

The Problem and Assessment Objective

There are certain issues faced by enterprise implementation when it comes to cutover because of their dependencies on hardcoded identifiers, breaks in dependency references, and improper management of security migration. This scenario is testing your knowledge in managing releases and lifecycles.

Architectural Approach

Describe the migration approach which focuses on environment independence and deployable solution:

• Hardcoded Dependency References: Explain that integration configurations, calculated field values, or code in Studio shouldn't depend on particular environment identifiers, such as particular WIDs or environment URLs. Instead, they need to be referenced using Reference IDs, Integration Map, or Workday Integration Services attributes (Environment Properties).

• Deployment Tooling: Explain how you are deploying solutions with the help of Workday Object Transporter (OX) or Solution migration tool. Deployment includes deployment of the main integration configuration along with other components including custom reports, calculated fields, integration system users, custom domains, and notifications.

Pre-Migration and Post-Migration Checklist

• It needs to be ensured that the security groups and business process configurations in the target tenant are set up prior to migration.

• Post migration of integration definition configuration, set up the Integration System User in the target tenant, make the required addition to security groups, apply the security changes, and test scheduled jobs.

• Data Privacy & Masking Consideration: Point out the refresh process of the environment. The refresh of Sandbox will overwrite the configuration with the production data and will point the test tests towards production URL if not followed by the runbook for pre/post refresh to obfuscate the external URLs and credentials.

Conclusion: Answer That Interviewers are Looking For

Apart from displaying your programming skills, you will also have to prove your enterprise architecture capabilities. This can be done by using Workday Integration Certification combined with OnlineITGuru Practice to acquire the knowledge of four key pillars that the interviewer expects from you:

• Simplicity is a Must: Make sure that you select the simplest native object that will provide success on the functional requirements side.

• Prepare for Disaster: Prepare for failures of downstream systems, expect malformatted messages from the vendor and allow user backdating of the records.

• Security in the Enterprise: Use the principle of least privilege, create Integration System Users and use modern token based authentication.

Platform Specific Requirements of Integration System: Take into account Workday’s multi-tenant architecture and minimize in-memory processing.