📣 New Workday connection for streamlining HRSM

[#1]

Hi Atlassian Community! 👋

A few weeks ago, we posted about the new 3P integrations in Automation for Jira, and today I wanted to spotlight the Workday integration (actions and a trigger). These new components are designed to streamline your HRSM business processes by connecting your Workday data directly into Jira Service Management.

Why Connect Workday with Jira Service Management?

Managing employee onboarding, offboarding, and HR queries often means juggling multiple tools and manual steps. With our new integration, you can automate these processes, reduce manual effort, and ensure a seamless experience for your teams.

Workday components

Worker Added to Workday (Trigger)

Use case: When a new hire is entered into Workday, onboarding tickets are automatically created in JSM.

How it works: Workday pushes a new worker event to Jira Automation, which then triggers your custom onboarding workflow—sending welcome emails, provisioning IT resources, and more.

Smart Values:
This trigger returns 8 default/system fields that with the new hire data which can be used to facilitate employee onboarding.

• {{workday.worker.name}} - Returns the full name of the worker from Workday.
• {{workday.worker.employeeId}} - Returns a worker's employee ID from Workday.
• {{workday.worker.workdayId}} - Returns the worker’s unique Workday ID from Workday.
• {{workday.worker.startDate}} - Returns the worker's start date from Workday.
• {{workday.worker.departmentName}} - Returns the name of the worker's department from Workday.

Retrieve Worker Details (Action)

Use case: At any point in the onboarding journey, fetch up-to-date employee details from Workday.

How it works: Pass a Workday ID to retrieve 26 default/system fields (e.g., Employee ID, Business Title, Hire Date, Email Address) and use them in your Jira workflows.

Smart values:
This action returns ~20+ smart values containing employee data including:

• {{workday.worker.firstName}} - Returns a worker's first name from Workday.
• {{workday.worker.hireDate}} - Returns a worker’s hire date from Workday.
• {{workday.worker.workEmailAddress}} - Returns a worker's work email address from Workday.
• {{workday.worker.managerEmailAddress}} - Returns a manager's email address from Workday.
• {{workday.worker.managerFirstName}} - Returns a manager's first name from Workday.

Visit our documentation, for the full list of available fields and smart values.

Expert tip: You can fetch additional Workday data at any stage of your workflow, and store sensitive info only on secure issues as needed.

---

Send Custom Workday Request (Action)

This action allows you to send a custom request to Workday using HTTP GET Post Put and Delete methods. Whether you want to access specific data with Workday REST API, retrieve a custom report (RAAS) or send a WQL query, this action can do it all.

Expert tip: Note that requests must be less than 30 seconds before they timeout. This is important to remember when fetching a RAAS report to ensure its size will be processed within the timeout window. You can also use these complimentary with Workday New Hire trigger and Retrieve worker action.

Smart values:

• {{workday.response.body}} – Returns the response body.
• {{workday.response.status}} – Returns the response status.

---

New Template: Import worker details from Workday to Assets

This use case ranks among the most requested by our customers: retrieving Workday RaaS (Reports-as-a-Service) report containing people data to power JSM workflows. To showcase how this can be done, we recently added a new template in the Automation template library to help you get started. This template runs on a schedule and automatically imports employee data from Workday into your JSM Assets using RaaS as the input.

Expert tip: For this template to work, make sure you have an appropriate schema in Assets already configured. In this example we are using Employee schema from People template.

Here’s how this template works:

• Runs on a schedule (e.g., every morning—customise this step to your needs)

• Send Custom Workday Request retrieves the RaaS report

• Iterates through each employee entry with a Branching logic where {{workday.response.body.Report_Entry}} = a new variable called employee.

• For troubleshooting, it’s helpful to look at what each employee entry looks like in the Audit log.

• Skips through payload entries without an email field using IF condition.

• For each employee, this rule performs a check to see if a record already exists in Assets using the email address field from the report data (any other unique identifier will work too).

• If no related object is found, it creates a new employee record in the Employee schema.

This is example of Workday RaaS returned in the JSON payload:

First Name	Last Name	Work Email Address	Department	Role
Ethan	Kim	olivia.carter@example.com	Marketing	Marketing Lead
Olivia	Carter	ethan.kim@example.com	Engineering	Software Engineer
Lucas	Nguyen	priya.patel@example.com	Human Resources	HR Specialist
Priya	Patel	lucas.nguyen@example.com	Finance	Financial Analyst
Sophia	Rossi	sophia.rossi@example.com	Product Management	Product Manager

In this example report we are using Workday's default fields only for illustration purposes. You can create any custom report with default or custom fields.

Try out the new actions and our template today and let us know what you think in the comments!

Kind regards,

Michael Fedulov
Product Manager, Jira Service Management

[James Rickards _SN_]

This is great progression towards competing with the vast library of integrations that ServiceNow boasts, making JSM a more attractive solution.

Now that Automations are getting viable for more business use cases, my biggest concern is maintainability and BCP. How do teams ensure their Disaster Recovery playbooks in their Business Continuity Plans are quick and as easy to implement as running terraform scripts to rebuild a compromised AWS infrastructure.

Before a business should heavily invest in building low code automations, it needs to know how it protects its low code environment against a rogue change (by either a stupid user, an internal threat or malicious external actor) which could cause severe loss of configuration in a short time period by editing or deleting automations.

Yesterday I accidently deleted one if block in an automation and I had to abandon the edit session and start from scratch. There is no undo feature during edit, and afterwards no in-built version control after I published my changes, which means no ability to recover from accidental or deliberate changes.  Disaster Recovery playbooks need to have detailed offline copies of all critical automations.  I doubt that many Atlassian Admins do that.

Personally, so it slots into existing DevOps team processes, I would love to see Atlassian sponsor the development of Terraform modules and include native export of automations to terraform configuration files, allowing us to build them from the UI in a sandbox environment, and promote them to production using modern DevOps tools and processes, but I don't see this happening as it does not seem very Atlassian.  The minimum I expect is some investment into a recycle bin and a "recovery" feature that stores versions of Automations, similar to how we can recover from deleted projects.