How to turnover-proof your Workday processes 💪 once and for all!

Read time: 10 minutes

Hey there! Mia here.

As promised, today I’m sharing a step-by-step guide on how to successfully upgrade your process owners from employees to Integration System Users (ISUs).

A couple of weeks ago in part 1 of this three-part newsletter, we covered why employees shouldn’t own your scheduled processes. If you missed it, I highly recommend you check it out below before diving into today’s newsletter (which is part 2 out of 3)👇

Fair warning… this guide is jam-packed with information. Some might call it… dense 😅 (it took me 16+ hours and a few shots of espresso to write this one).

This guide is sooo stuffed with information, that we decided to split it into 2 newsletters for digestibility. Here’s what to expect…

With that, grab your caffeinated beverage of choice, and let’s dive in! 🌊

Step 1: Assess Your Processes

In your Production tenant, run the WD-delivered Scheduled Future Processes report. Check the “Owned by User” column to glance at which of your processes are owned by employees rather than ISUs.

Pull this report down to Excel—you’ll use this spreadsheet to plan your upgrade process. Delete rows that contain processes already owned by ISUs (you can add a filter to your headings and filter or sort column F, “Owned by User”, to quickly identify these processes).

Next, sort the last column (column J), labeled “Status”. Identify which processes are suspended or expired, and decide which of these processes you’d like to include in your upgrade process. As a general rule of thumb, if you foresee the process becoming active again in the future, include it in your upgrade!

How many processes did you identify for your upgrade!? Did the number surprise you?

Step 2: Understanding ISUs and ISSGs

The goal of this effort is to ensure that every scheduled process is owned by an ISU—and that each ISU has the security it needs to successfully run the process it owns, via an Integration System Security Group (ISSG). So before we go any further, let’s break down ISUs and ISSGs.

An Integration System User is a system user that isn’t connected to a real person—it’s a permanent Workday Account that lives in your tenant. While ISUs are typically used for running integrations and web services, their secure, automated, and permanent nature makes them perfect for owning and running your non-integration scheduled processes as well.

To own and run your processes, ISUs need security access, just as any other Workday user would. ISUs are granted security via Integration System Security Groups. ISSGs are a type of security group. Just as user-based security groups are assigned to Workday users, ISSGs are assigned to ISUs. Like many other security group types, ISSGs can be constrained or unconstrained. Constrained ISSGs filter access by organization(s), while unconstrained ISSGs provide system-wide access.

Step 3: Create Your Upgrade Plan

Like all well-built initiatives, it’s crucial to plan before executing. Your objective for this step is to map an ISU/ISSG (new or existing) to every scheduled process on your upgrade list.

Within the Excel spreadsheet you created in step 1, create 3 new columns labeled “ISU”, “ISSG”, and “New or Existing”:

Next, let’s discuss what to consider when assigning an ISU/ISSG pair to each scheduled process…

Review your existing ISUs and ISSGs…

You’ll likely need to create new ISUs and ISSGs to own most of the scheduled processes on your upgrade list. For good measure, however, become familiar with the ISUs and ISSGs that already exist in your tenant.

First, run the WD-delivered report, “All Workday Accounts”, and filter for contains “ISU” on the User Name column:

Scroll through the results to see what’s there! Are there any ISUs that look like they were set up to own scheduled processes (e.g. ISU_Reporting, ISU_HR Admin, etc.)?

Next, run the “View Security Groups” report, filtering for unconstrained ISSGs. Explore what’s there:

Take note of what’s already existing (that you may be able to utilize) as you proceed!

Assess your process types…

Take a look at column B on your Excel spreadsheet, “Process Type”. Sort this column in ascending alphabetical order. There are 3 types of scheduled processes in Workday we’ll cover today: Integrations, Jobs, and Reports. You may or may not have all 3 process types on your upgrade list.

Integration and Report processes are fairly self-explanatory. These are scheduled integrations and scheduled report output deliveries, respectively.

Jobs, however, are more diverse. Jobs are Workday processes you can set up to run automatically (in the background) on a frequency of your choosing. A few examples are…

• Alert Notifications

• Passive Events

• Mass Submit Time

• Mass Autofill from Schedule

• Start Performance Review for Organization

• Find Duplicates

• Learning Campaigns

As you create an execution plan for upgrading your process owners, it’s helpful to segment by process type (more on this shortly!).

Investigate integration processes in need of upgrade…

Now that you’ve organized your processes by type, do you see any integration processes that are owned by an employee? If you do, let’s investigate a bit further…

First, check the integration system itself to see if it’s attached to an existing ISU (Task: “View Integration System”):

Typically, it should be. If you have integrations that aren’t owned by ISUs, it’s okay! That’s what we’re here to fix. However… more so than jobs and reports, I’d expect that your integrations themselves, and their scheduled processes, are already owned by ISUs. Whoever built your integrations—this was part of their job. If they didn’t set up an ISU and ISSG for the integration, they didn’t finish the job.

If the integration system is owned by an ISU, whoever set up the process for the integration probably just forgot to transfer ownership of the process as well. You can use the existing ISU/ISSG pair as the new owner of the process—just make sure you test to confirm no additional security is needed (we’ll cover testing in step 7). Note the ISU/ISSG on your spreadsheet and mark the pair as “Existing”.

If the Integration System itself is owned by an employee… yikes 😳 Circle up with your integrations team pronto and get that fixed! If you’re in the trenches alone, stay tuned for some configuration tips coming next week in step 5.

Complete your ISU/ISSG assignments by process type…

While there’s no right or wrong formula for mapping ISUs/ISSGs to each process, below are some guidelines by process type…

Scheduled Integrations (1:1)

As you create new ISU/ISSG pairs, consider whether you are building the pair to own just one scheduled process, or many. This ratio is an important setup consideration—it will impact how you name your ISU/ISSG pair, and what security you grant to the ISSG. In this section, next to each process type, I’ve listed the recommended ratio for ISU/ISSG pair to processes (e.g. 1:1).

If this isn’t making sense yet, keep reading!

Integration processes should be assigned their own ISU, with a uniquely provisioned ISSG. For example, let’s say you need to upgrade the owner of your E-Verify integration process named “INT0123 E-Verify - Daily Sync”. On your planning spreadsheet, assign the process an ISU named “ISU_INT0123 E-Verify” and an ISSG named “ISSG_INT0123 E-Verify”. This ISU/ISSG pair will be used for this integration process only (1:1).

Here’s why every integration process needs its own specialized ISU/ISSG pair…

ISUs that own integrations typically require get/put and modify security access that allows the system user to modify data, send data outside of Workday, and receive data from outside of Workday. There is risk associated with the transfer of data in and out of Workday, and with the modification of data within Workday. For example, unauthorized employee data could be leaked to a third party, or employee data could be changed erroneously, if the ISU is compromised when the process runs. ISU/ISSG pairs that own integrations are specialized for just one integration to mitigate risk—minimizing the access that each ISU has reduces the severity of potential breaches.

Scheduled Jobs (1:1, 1:Many, or 1:All)

You’ve got options when it comes to creating ISUs and ISSGs to own your scheduled jobs. Similar to integrations, you could have every scheduled job owned by a unique ISU/ISSG pair. The security needed to run each job is highly specific, so you’d create an ISU/ISSG pair that’s specialized to own and run just one type of job. For example, you could assign your “Find Duplicates” process an ISU named “ISU_Find Duplicates” with an ISSG named “ISSG_Find Duplicates”. The ISSG will be granted only the security it needs to run the Find Duplicates task.

Alternatively, you could opt to create several ISU/ISSG pairs to own different categories of jobs. For example, you could create ISU_Alerts/ISSG_Alerts to own your alerts, ISU_Time Tracking/ISSG_Time Tracking to own your Time Tracking related jobs, etc.

Lastly, you could instead create one master ISU/ISSG pair to own all of your scheduled jobs. You might name this pair something along the lines of ISU_HRIT Admin/ISSG_HRIT Admin.

Security auditors tend to favor a more segmented approach (a unique ISU/ISSG pair for every job type). While scheduled job ownership is low risk compared to say, integrations, more segmented = more secure (and more easily audited).

That said, I have seen organizations opt for a 1:Many or 1:All approach for job-owning ISUs/ISSGs. Since the ISUs that will own your scheduled jobs are restricted to the confines of your Workday environment, provisioning each ISSG with more access is generally okay, as long as you’re aware of the security considerations above.

Scheduled Reports (1:All)

For ease of setup and maintenance, I recommend creating one master ISU to own all of your custom reports and scheduled report processes. This ISU and ISSG would typically be named “ISU_Reporting” and “ISSG_Reporting”, respectively.

Similar to jobs, a 1:All ratio is acceptable for your scheduled reports. Since the ISU that will own your report processes is, again, restricted to the confines of your Workday environment, and will only need view access, provisioning the ISSG with the security it needs to own and run all report processes is fine.

Your planning is now complete!

At this point, within your spreadsheet, every scheduled process should have a new or existing ISU and ISSG assigned to it.

✅ Once you’ve completed step 3, you should know exactly how many ISU/ISSG pairs you’ll be creating.

Now that your plan is in place, it’s time to configure! 🤩

Step 4: Create Your ISUs (in a Test Environment)

Make sure you complete steps 4 - 6 in a test environment. I recommend using a recently refreshed copy of Preview or an Implementation tenant, as you may need more than a week or two to complete your testing.

To create an ISU, navigate to the task, “Create Integration System User”.

Name your ISU, and set a password. Make sure you remember this password, as you’ll need it for testing!

Ensure that the “Do Not Allow UI Sessions” box remains unchecked for now. Keeping this box unchecked will allow you to log into the tenant as your ISU for testing in step 7.

Note that this box should only be left unchecked in testing tenants if you’ll need to manually log in as your ISU for testing purposes. If you notice an ISU in PROD that has this box unchecked, fix that right away—it’s a security risk.

Repeat this step until all ISUs on your spreadsheet have been created.

🎉 🎉 🎉

That's it for part 2! You're now about halfway through turnover-proofing your processes 💪

We hope you feel empowered with all the details. If you’re feeling overwhelmed, don’t worry—you’ve got a week to digest all this before we keep going!

Stay tuned for part 3, next week 😎

As always, thank you for reading.

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

Ceci & Mia

Co-Founders of Well Built Solutions

P.S. Ready for more?! 👉 Check out part 3.