💪 Turnover-proof your Workday processes—the FINALE!

Read time: 12 minutes

Hey there! Mia here. Last week, I shared the first half of a step-by-step guide on how to successfully upgrade your process owners from employees to Integration System Users (ISUs).

Today, I’m sharing the second half of the guide to help you get the job done 😎

If you missed last week’s newsletter (part 2 of 3), I highly recommend you check it out before diving into today’s (which is part 3 of 3). If you’re new to this three-part series, don’t worry—you can catch up below👇

Here’s the agenda for today…

FYI—this half of the guide is SO jam-packed with info that we couldn’t fit your release prep and brainteaser segments today (who knew there were email length limits 😅). We’ll be back with those next week!

With that, it’s time to finish turnover-proofing your processes, my friends 🛠️ Here we go…

Step 5: Create Your ISSGs (in a Test Environment)

Last week, we ended part 2 of turnover-proofing your processes by creating your integration system users (ISUs). Now it’s time to create the integration system security groups (ISSGs) that will give your ISUs access to own and run your processes.

As a reminder, steps 4 - 6 should be completed in a test environment. I recommend a recently refreshed copy of Preview or an Implementation tenant as opposed to Sandbox—you may need more than a week or two to complete your testing.

Create the security groups…

Creating a process-owning ISSG itself is straightforward. Here’s how in 3 steps before we dive into provisioning more detailed security…

1. Run the Create Security Group task. Create an “Integration System Security Group (Unconstrained)” security group. Unless you have a reason to restrict ISSG access contextually (e.g. by organization), your process-owning ISSGs will be unconstrained:

2. Once you create the ISSG, add the appropriate ISU (per the upgrade plan Excel spreadsheet you created last week in step 3) in the “Integration System Users” input.

   

3. There are 2 base-level permissions I recommended giving your ISSG off the bat. These permissions provide access to the complete Scheduled Future Processes report for testing in step 7:

• Domain Security Policy: Custom Report Creation (View/Modify)

• Domain Security Policy: All Background Processes (View Only)

Provision and activate this access during your initial ISSG setup using the Maintain Permissions for Security Group and Activate Pending Security Policy Changes tasks, respectively.

I’ve found these permissions to be the most efficient way to provision base-level, process-ownership access. Ultimately, your ISU will only be able to run processes that it specifically owns. This base-level access comes with little risk and positions you for a smooth testing process.

Provision security for your ISSGs…

I’ll give it to you straight—provisioning security can be tough.

There’s no one-size-fits-all approach to determine what security is needed to run and own each job, report, and integration process. If you’re not well-versed in Workday security, you’ll likely need support from a security specialist and/or product area experts.

Broken down by process type, here’s how to approach nailing down what permissions your ISSGs need…

Jobs

First, a quick callout for alerts, which are usually a large proportion of all scheduled jobs. To own and run your alert jobs, your ISSG will need access to:

• Domain Security Policy: Notification Alerts (View/Modify)

Your alert-owning ISSGs will also need to own the report your alert is built on, and have access to any tasks and content within the alert itself.

For most other scheduled jobs, the View Security for Securable Item report is a great place to start. Let’s say you need to create an ISSG for your Mass Submit Time process. Here’s how to determine what security your ISSG_Mass Submit Time needs:

1. Run the View Security for Securable Item report for the Securable Item “Mass Submit Time” to determine what domain(s) secure the task.

2. Click the “View Security” button on each Task, Report, and Background Process to review the domain(s) that secure the task.

The domain security policy that secures the Mass Submit Time task is “Process: Mass Submit Time”. Notice that the permission required is “Modify”. To run the Mass Submit Time process, “View” permission isn’t sufficient.

3. You’re not done yet! Next, consider what other security is needed to successfully run the job—in this case, to submit time. For example, your ISSG_Mass Submit Time will also need:

   • Business Process Security Policy: “Submit Time” Initiating Action access on the Enter Time business process

   • Domain Security Policy: Worker Data: Time Tracking (View/Modify)

If you’re not sure where to start, a quick Community search is typically fruitful! 🍇

4. Run the task Activate Pending Security Policy Changes to activate the security you’ve provisioned. Thoroughly document your activations with a detailed comment, even in your testing tenant! You can run the View All Security Timestamps report throughout testing to remember what changes you made.

Reports

To run your scheduled report processes and deliver the report output, your ISSG needs access to these two domains:

• Domain Security Policy: Report Output Sharing (View/Modify)

• Domain Security Policy: Scheduled Report Processes (View/Modify)

Beyond these permissions, your ISSG also needs full access to the custom reports it will run and own. This includes all data sources, fields, calculated fields, filters, prompts, etc.

As I mentioned last week in step 3, I recommend creating one master ISU/ISSG pair to own your report processes.

Begin by reviewing your list of scheduled reports to understand what type of data your ISU will need access to. What data sources are your reports built on? Are most of your scheduled reports worker-based?

Once you’ve assessed the contents of your scheduled reports, there are various ways you can approach provisioning security. Here are two ideas to get your gears ⚙️ turning…

Copy Existing Security Group Permissions

Use existing security groups as a base for your ISSG. For example, let’s say you know that HR Administrators can successfully run all of your scheduled reports. You can begin the provisioning process by copying HR Administrator permissions to your ISSG_Reporting group. Use the task, “Maintain Permissions for Security Group”:

If your reports include business process transaction data, note that your ISSG also needs “View All” access on those business process security policies.

Analyze Scheduled Report Security via Custom Reports

Create custom reports to help you determine what security is needed to fully access and run a custom report.

Build these reports on the “All Custom Reports” and “All Fields” data sources. These data sources can provide insight into the security needed to view all fields and calculated fields used within your scheduled reports.

Integrations

As we discussed last week, more so than jobs and reports, I’d expect that your integrations themselves, and their scheduled processes, are already owned by ISUs. If you’ve got a significant amount of owner upgrading to do for your integrations and their scheduled processes, work with a trusted integrations expert to fix this (we know a few great ones if you need recs!).

If you’re in a bind and need to figure it out yourself, here’s my best advice…

There’s solid documentation on Community for common integrations. For example, if you search “E-Verify Integration” on Community, you can find the Workday documentation for setting up the E-Verify Integration. This documentation lists the Get and Put access your ISSG will need, among other setup steps.

You can also use the View Security For Securable Item report I mentioned earlier to scope security for the web services, report data sources, etc. that your integration uses.

Before we move on…

Step 5 isn’t complete until you’ve finished testing. Provisioning security is often an iterative process. As you test in step 7, you may come back to step 5 to troubleshoot and nail down permissions that your ISSGs are missing. If you hit roadblocks while testing, keep going! You’ve got this 💪

Step 6: Transfer Ownership (in a Test Environment)

Once your ISUs and ISSGs are set up, it’s time to transfer ownership of your processes! But first…

Transfer ownership of all underlying custom reports that are scheduled or referenced in alerts to the ISU that will own its process. The configuration within a process should also be owned by the ISU to prevent failures.

Next, you can finally transfer ownership of scheduled future processes. Unfortunately, this is a tedious, manual process—ownership is transferred one process at a time.

✏️ And take note… when you transfer ownership of a process, the process Share settings are erased (one of those Workday “quirks” you should be aware of). Here’s a quick trick to prevent this.

To transfer ownership of a process, run the report, Scheduled Future Processes. From the “Scheduled Process” column, click on the related actions button, hover over “Scheduled Future Process”, and click “Transfer Ownership” (DON’T forget to use the trick linked above!).

If your ISSG lacks access needed to own a process, your intended ISU won’t be an option at this step. If this happens to you—no biggie! Return to step 5 and troubleshoot security.

Step 6 is complete once all processes on your list, and their underlying components, are owned by their newly assigned ISU.

Step 7: Test, Test, TEST!

The purpose of testing here is to confirm that your ISUs can successfully run the scheduled processes they now own.

Reopen the upgrade plan Excel spreadsheet you created last week in step 3. Add a column or two in which you can track your testing outcomes. Ensure you document your testing! Once these upgrades are moved into PROD, you DON’T want any issues traced back to lazy, undocumented testing.

When testing scheduled processes, it’s not uncommon to receive a false success message. It’s incredibly important to support your testing with tangible proof that the process produced its intended outcome. I recommend taking screenshots of every successful test to show a) the ISU ran the process successfully and b) proof of the expected outcome.

Okay, I’ve emphasized the importance of documenting your testing 😉 Onward…

Last week in step 4, when you created your ISUs, remember how you left that “Do Not Allow UI Sessions” box unchecked? That setting is what will now allow you to log into your testing tenant as each ISU.

Before you can begin testing, there’s one additional setup step to complete (you won’t be able to test without it)…

💡 Add your new ISSGs to your testing tenant’s Authentication Policy to allow the ISUs to log in by username/password…

Run the Manage Authentication Policies task and edit the policy for your test environment. If the policy already has a rule for integrations or APIs to log in by username/password, add all of your new ISSGs in the “Security Group” input. If it doesn’t, you can add a rule as follows:

Activate All Pending Authentication Policy Changes once you’ve set this up.

Now, you can finally log in as your ISUs to test your processes…

1. Log into your testing tenant as your ISU using the username and password you set when you created the ISU in step 4 (the username is just the name of the ISU).

2. Run the report, Scheduled Future Processes. Filter the “Owned by User” column for the ISU that you’re logged in as.

3. Click the related actions button on the Scheduled Process, hover over “Schedule Future Process”, and click “Run Now”. On the next page, check the box to “Confirm” the run, and press OK.

If the process fails or doesn’t produce the results you were expecting, the most likely culprit is security (or lack thereof). Return to step 5 and troubleshoot to determine what additional access your ISSG needs to successfully execute the process.

Confirming that each process ran successfully will look a bit different for each process type…

Jobs:

For most scheduled jobs, mock up a test scenario to verify that the process ran successfully. This requires some job-specific subject matter expertise. For example, if you’re testing a Mass Submit Time process, here’s how you’d mock up a test:

1. Create a time block or two using the Enter Time task to add time for a worker in the target period.

2. Run the scheduled Mass Submit Time process “now” logged in as the ISU.

3. Manually check the worker’s time calendar to confirm that the time block you entered was submitted by your process.

Every job type will require a different mock-up. For example, if you’re testing a Find Duplicates process, ensure there’s at least one set of duplicate worker records in your tenant to be merged—create a set if you have to!

Alert jobs are simpler to test. Run the alert process as your ISU, and proxy as a known target recipient to ensure they received the notification as expected.

Reports:

First, search for and run the underlying custom report logged in as your reporting ISU. Confirm that your ISU can access and run the full report as its owner. If everything looks good…

Run the scheduled report process, and confirm a target user receives the output as expected. Proxy as the target user to confirm the output is in their notifications and “My Reports”. Review the file to confirm the data was output as expected.

Integrations:

Testing integration processes is more elaborate, as it involves data coming into Workday or being sent outside of Workday. Coordinate with your integrations team and/or third parties as needed—a test environment typically needs staging outside of Workday.

When testing integration processes, ensure that the “Restricted to Environment” setting on your process is updated to your test environment.

For job and report processes, you don’t need to change the “Restricted to Environment” setting—even if it’s listed as PROD. The processes will still run in your test environment, and will not run in Production.

Step 8: Migrate Your Work to Production

Once you’ve completed your testing (and you’ve got the receipts to prove it!), it’s time to replicate your work in PROD. “Migrate” isn’t quite an accurate term here, as the configuration components you’ve built in this process aren’t migratable—you’ll need to rebuild your work manually.

Repeat steps 4 - 6, this time, in your Production tenant:

1. *Create your ISUs (step 4)

2. Create your ISSGs (step 5)

3. Transfer ownership of the processes (step 6)

This time around, your work is unambiguous. You’ve completed all the hard work of planning, provisioning, and testing. Now, you’ll just need to carefully and accurately replicate the setup in Production.

✏️ *Take note… there are two (very important!) additional setup steps when creating your ISUs in Production:

1. Remember that box we left unchecked in step 4? This time, make sure you check the “Do Not Allow UI Sessions” box. This locks down the ISU account, ensuring that no person or AI can log into your Production tenant as your ISU.

2. Once you’ve created all your ISUs, run the task, Maintain Password Rules. Add your new ISUs to the “System Users exempt from password expiration” input to ensure that your ISUs never expire.

There you have it! Once the transfer of process ownership has been completed in Production, your processes are officially turnover-proofed ✨

In the weeks following your completion of this effort, keep a close eye on your upgraded processes to ensure they run smoothly.

🎉🎉🎉

If you feel like you’re constantly putting out fires in your tenant, turnover-proofing your processes is your first step to moving from reactive —> proactive.

While the process can be tedious, it’s worth it! We’ve never worked with a client who regretted turnover-proofing their processes—but we have worked with numerous teams who regretted putting it off.

As always, thank you for reading.

We’re celebrating you and your pursuit of a Well Built Workday 🥳

See you next week!

Ceci & Mia

Co-Founders of Well Built Solutions