I am working in JSM Cloud Premium and experiencing a frustrating latency issue with an approval work

[Fadi Messaoudi]

Hi everyone,

I am working in JSM Cloud Premium and experiencing a frustrating latency issue with an approval workflow.

The Scenario: When an access request ticket is created, we have an approval step that requires the manager of the reporter. We pull this manager data (via Azure AD) to populate the "Approvers" field. and keep in mind that the access it's choosen from an assets field to route the ticket depending on reporter city 

The Problem: The issue is that the "Approvers" field remains empty for several minutes after the ticket is created. It takes anywhere from 4 to 10 minutes for the manager's name to finally appear in the field so the approval process can actually start.

I have already contacted both Atlassian Support and the plugin support. They told me everything is technically functioning as designed with no errors in the logs. However, waiting up to 10 minutes just for an approver to be added creates a bad experience for our users.

Has anyone experienced this specific delay with syncing manager data to the Approvers field? I am looking for practical workarounds to fix this lag and get the Approvers field populated instantly.

Thank you!

[Marc -Devoteam-]

Hi @Fadi Messaoudi 

As @Arkadiusz Wroblewski is stating, this is true.

You could start using assets and in relation a 3rd party app (see developer PIO), to synch AD data into assets, then you could start using the information directly.

On an automation rule that upon creation fills the approver field based on the ticket reporter.

[Arkadiusz Wroblewski]

Hello @Fadi Messaoudi 

I think problem are your Concept and Expectations.

This is not a strong pattern for “instant approval” when the approver still has to be fetched asynchronously from Azure after the ticket has already been created. From a process and control standpoint, that introduces unnecessary uncertainty at the very point where the workflow is supposed to be immediate and deterministic.

A cleaner, more reliable approach is to make sure the manager or approver data is available before the request is created. If that is not possible, then the better design is to keep the request in a pre-approval or pending-initialization state, and only transition it into the actual approval status once the Approvers field has been fully populated.

Woulnd´t be better for you to pre-sync that manager information somewhere Jira can read immediately, for example into a Jira field, directory-backed user data, or an Assets object that is already local to the site?

Then set Approvers from that local value on create, or transition into the approval status only after the field has been filled.