nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

📣 Streamline your multi-tool processes with HR, Sales and IT automation actions

Michael Fedulov

Update July 8, 2025
We’re thrilled to add another integration to the list!

New actions: Google Cloud Platform

Using the new Google Cloud (GCP) connector, you can quickly integrate GCP data directly into your Jira Service Management workflows.

New actions:

Create virtual machine on Google Cloud Platform
Get projects from Google Cloud Platform
Get project details from Google Cloud Platform
Get zone details from Google Cloud Platform
Start virtual machine on Google Cloud Platform
Stop virtual machine on Google Cloud Platform

Hi Atlassian Community! 👋

We’re thrilled to announce 15 new automation actions that integrate with several commonly used HR, Sales, and IT systems! We know that teams are often require to work on complex processes - like onboarding - across multiple tools. This often results in a lot of manual work and context switching. That’s why we’re on a mission to streamline your processes by supercharging JSM with new integrations. Our goal is to make it easier for teams to get work done by automating processes across multiple tools, making data readily available wherever it’s needed.

What’s new

New actions for automating IT Operations

These new actions can be used for automating your user lifecycle management processes, including onboarding and access management.

New actions: Update user configurations on Microsoft Entra ID

The new Microsoft Entra ID connector enables IT admins to enhance Enterprise Service Management by seamlessly integrating user data from Entra ID.

New actions:

You can also customise your request with Send custom Entra ID request action. This action allows you to send a custom request to Entra ID using HTTP Get, Post, Put and Delete methods. This action can be used with any valid Entra ID endpoints for scenarios where predefined actions cannot meet your specific requirements.

Expert tip: Before creating a connection between your project and Entra ID using custom request action, you need to register an app in the Azure portal. Read more about how to register an app in Microsoft

Smart values:

{{entra.response.body}} – Returns the response body.

{{entra.response.status}} – Returns the response status.

New action: Send Custom Okta Request

This action allows you to send a custom request to Okta using HTTP Get, Post, Put and Delete methods. This can be useful for automating tasks that can’t be achieved by the predefined Okta actions. Read more about Okta APIs

Expert tip: You can use this action complimentary with 4 existing Okta actions Create user & Retrieve user, Add user to a group & Suspend user

Smart values:

{{okta.response.body}} – Returns the response body.

{{okta.response.status}} – Returns the response status.

New actions for automating HR Operations

New action: Send Custom Workday Request

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 or retrieve a custom report (RAAS), 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 action: Send Custom Docusign Request

This action allows you to send a custom request to Docusign using HTTP Get, Post, Put and Delete methods. This can be useful for automating the sending, signing, and tracking of electronic documents, and other e-signature workflows.

Expert tip: This integration currently only supports the Docusign eSignature (REST) API. This uses the following API endpoint base paths:

https://{server}.docusign.net/restapi (production environment)
<a href="https://demo.docusign.net/restapi" rel="noopener nofollow noreferrer" target="_blank">https://demo.docusign.net/restapi</a> (developer environment)

Smart values

{{docusign.response.body}} – Returns the response body.

{{docusign.response.status}} – Returns the response status.

New actions for automating Sales Operations

New actions: CRM sales data

Salesforce Specific.png With this new connector, you can easily automate and integrate sales case and opportunity data into your existing workflows.

New actions:

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

Kind regards,

Michael Fedulov
Product Manager, Jira Service Management

Comments

Jeff Patterson-admin

Nice! Will this also be available on the Jira Cloud Software platform? We want to easily fetch data in Automations from Okta/Workday from there too... Thx

Danny Harris_nlmsd2

OMG this is amazing!

Ryan_lsp8w2

@Michael Fedulov, when using the built-in Entra identity management operations, it appears to only permit establishing the connection as an Entra user. These tokens are typically short-lived, or possibly restricted by conditional access policies, and will likely result in connections breaking unexpectedly when they expire. Is it possible to use an app registration with a client secret like the custom request uses? That would allow for limiting permissions on the azure side and a predictable expiration date on the connections.

Michael Fedulov

Hi @Jeff Patterson-admin, thank you for your comment! These connections are made available in Automation for Jira and can be accessed across Jira products family including Jira Software. It is worth mentioning that some require Jira Service Management Premium or Enterprise licence. Please follow our documentation for more details!

Michael Fedulov

Hi @Ryan, thank you for your comment! You are correct, currently Send Custom Entra Request action and other specific actions connect via the OAuth 2.0 Authorization Code Flow (3LO) as we don't support API keys. With Send Custom Entra Request action you can use separate app registration while specific Entra actions connect via Atlassian registered app.

This is very useful feedback, if you could please elaborate how this might be limiting you that would really help us prioritise making changes to the current flow.

Ryan_lsp8w2

@Michael Fedulov thanks for your reply. I'm working on an automation where I need to add a user to a group in Entra, so the built-in component is ideal. However, since it's an important process, we don't want to risk the connection expiring after hours, and we'd prefer to have a predictable and infrequent key rotation. Azure client secrets can be valid for up to two years.

I started down the custom Entra request route, but we hit a couple of roadblocks. First, there isn't an option to continue the run on a failure result like we have with the "Send web request" component. If a user is already a member of a group, Entra returns a failure code and the flow halts. We can put it into an If/Else block, but there isn't a way to extract the failure message in the next step to know if the failure was because the user is already part of the group (which we could safely ignore) or some other reason. Granted, it's in the audit logs, but we'd prefer not to have to check the audit logs for benign failure conditions.

To sidestep this issue, I tried using another custom request to check in advance if the user is a member of the group, but that requires iterating over a list of group members or the list of groups the user is a member of. Due to scoping limits and the asynchronous nature of loops in automation rules, I can't operate off the result back in the main branch of the automation. For example, if I loop over every group and find a match, I'd like to set a global variable "isMember" to "true" so I can evaluate that outside the loop and skip the step to add a group member. If I understand correctly, variables in loops are locally scoped and global variables can't be set inside them. Even if they could, it sounds like subsequent actions may already be executed in parallel while the loop is being evaluated. This process would be more easily handled by the built-in component, but the authentication method is a blocker for us.

I think either supporting client secrets as an auth method for the identity management components or allowing the custom request to continue to run on a failure response would allow us to move forward.

Thanks again!

KennPangan

This is really exciting to see. I work at eesel, where we focus on helping teams connect internal tools and automate support workflows.

We’ve actually been experimenting with using similar multi-tool actions in our setups, especially around user provisioning and onboarding flows. Being able to combine Jira Service Management automations with tools like Entra ID, Okta, and Workday is huge for reducing manual handoffs and making processes more reliable.

The detail around using custom requests and handling status codes is especially helpful, thanks for sharing that. Curious to hear how others are tackling error handling in these more complex automations.

Great work to the Atlassian team on these updates.

James Rickards _SN_

This is great progression towards competing with the vast library of integrations that ServiceNow boasts.

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.

Tobias Bosshard

I completly agree with @Ryan, thanks for your input.
I am struggling with the following problem: when I run an action with “Check if user is enabled in Entra ID”, I only get an evaluable result if the user is deactivated in Entra. If the user has already been deleted (and no longer exists), the automation returns an unevaluable error and I cannot use an if condition to detect when a user has been deleted in Entra.

Ryan_lsp8w2

@Tobias Bosshard, what if you set a global variable to false in the main branch, and then set it to true in the If/Else block after evaluating the output of the "Check if user is enabled in Entra ID" step? If the step fails because the user doesn't exist, the variable will remain false. Assuming you only want to operate on active accounts, the next step in the main branch would be a conditional evaluating if the variable is true and continue on from there.

If you need to distinguish between deactivated and non-existent accounts, you could have 3 values for the variable. Say the variable name is userState - initialize the variable with the value of deleted. If the check fails, assume the user is deleted and leave the variable value. If the check is successful, but the user is inactive, set the variable to inactive, if the check succeeds and the user is active, set it to active.

This assumes that the check doesn't fail for some other reason (e.g. token expiration) - it would still be helpful to evaluate the actual response to know if that was the case, but this could get you closer to what you need.

We ended up going with custom Entra requests because it permits authentication with client secrets which have a predictable expiration. We're doing a similar process with setting and checking variables as described above. Iterating over group members was problematic, so we flattened the list of members into a comma-separated string and run a regex match against the string to see if the user is already a member of the group.

Risto Majamaa

@Michael Fedulov Any idea what could be wrong with trying to establish connection to Entra ID when using these standard actions, like:

Get user details from Entra ID
Add user to group in Entra ID

I can sign in, but it does not proceed to the step where I am prompted to authorize Atlassian to access my Entra ID tenant. Instead, I get immediately returned back to the automation page. Entra ID.png

I have opened a ticket with Atlassian Support, but they haven't been able to resolve this. Is there something in Entra that needs be done to allow these connections? Even Rovo suggests, that "For these standard actions, you do NOT need to register a custom app in Azure—Atlassian uses its own integration."

With the custom ID requests, I am able to establish connection as I have registered the app in Entra ID and I am using the secret from there.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-desk-cloud

jira-service-management-cloud

jira-service-management

jsm-cloud