Workday Spoke FAQ 1. Are the Workday Spokes based on the SOAP or REST API? Primarily, both Workday HR and Workday Financials Spokes are based on the original Workday Public SOAP APIs that are available here. An administrator does not need to configure any REST API connection alias in the Spoke, unless they need to interact with the following actions: Get My Reporting Structure Look up Object Custom Fields Update Object Custom Fields Look up Inbox Items Look up Merit and Benefit Plan Details of an Employee Look up Holiday Calendars Reference WID of an Employee Look up Schedule Calendars Reference WID of an Employee Look up Holiday Calendars of an Employee Although Workday has started to migrate their web services to REST based, most of the core integration functionalities are still based in SOAP. ServiceNow will keep watching on the progress of the Workday REST API and will reflect in the Spokes accordingly in the future. 2. Why the post processing script of Workday Spoke is so complicated? The nature of Workday SOAP API is extremely nested. They are some of the most nested XML web services in the industry. The script of the Workday Spoke reflects that complexity as a result. To provide a sense of how nested the response XML message is, below is an example just to get a home phone number: <bsvc:Get_Workers_Response> < bsvc:Response_Data> <bsvc:Worker> <bsvc:Worker_Data> <bsvc:Personal_Data> <bsvc:Contact_Data> <bsvc:Phone_Data> < bsvc:Usage_Data> <bsvc:Type_Reference> <bsvc:ID> HOME</bsvc:ID> </bsvc:Type_Reference> </ bsvc:Usage_Data> <bsvc:Phone_Number> 4151231234 </bsvc:Phone_Number> </bsvc:Phone_Data> </bsvc:Contact_Data> </bsvc:Personal_Data> </bsvc:Worker_Data> </bsvc:Worker> < /bsvc:Response_Data> </bsvc:Get_Workers_Response> First, you will need to go 10 level down to determine whether the phone type is for home, office, or others. Then based on the right array bucket, the API references the associated home phone number. The post processing script also needs to reflect accordingly because of this complex nature to begin with. The advantage and Workday’s original intent of this design is its reusability. The similar XML structure is applicable to government IDs, home address, etc. However, customer will need to get the first design pattern straight, then the same scripting design pattern can be easily reused and modified afterwards. The Flow Designer and Workday Spoke makes this nested XML structure easier to consume. The Workday Spoke actions themselves have exposed some of the complicated nested XML elements already as drag-n-droppable format. Combine that with the Flow Designer, you can now easily find the home phone number in this scenario: Study the post scripting design patterns from the Workday Spoke actions. Use them as the references to just expose other nested XML elements only first. Then use Flow Designer to actually consume the associated elements. 3. How come Workday Spokes are missing many other web service operations? Workday Public APIs are enormous, not only the number of total web service operations, but also the number of request and response message fields. The current Workday Spokes cover the use cases that are popular from the ServiceNow integrations perspective. However, Spoke is extensible. With the current design pattern in the Workday Spoke, an administrator can study and tailor the Spoke per user requirements. Additionally, Spoke allows customers to build new SOAP action by simply parsing a WSDL. Here are some references: SOAP Step XML Parser Step XML Document Scripting 4. How to pull in worker deltas from Workday? The best practice to pull in worker deltas are: Transactions entered today but effective from the past to present: This is the scenario where a HR Ops needs to catch up on the data entry, correct data, or urgently add a new worker. Transactions entered today or in the past but effective in the future: Most transactions are entered this way. For example, a new hire, voluntarily terminate a worker with a two-week notice. To cover both situations, we suggest entering these values for the Update From, Update Through, Effective From, and Effective Through input parameters: From Past to Present: Update From: Last Successful RuntimeUpdate Through: Current DatetimeEffective From: 1900-01-01Effective Through: Current Datetime From Present to Future: Update From: 1900-01-01Update Through: Current DatetimeEffective From: Current DatetimeEffective Through: Current Datetime + how often you poll from Workday. If every hour, + 1 hour; if once everyday, + 1 day. Below is how to build the sample flow above in Flow Designer. Assume It will poll the deltas every hour. Create a simple get current time helper action. It can be created at the Global scope level. No input variable is needed: 3. Expose the output variable 2. Enter the datetime parameters accordingly for the Past-to-Present delta Look up Workers flow: 3. Enter the datetime parameters accordingly for the future delta Look up Workers flow: These should cover most, if not all, deltas of the workers from Workday.