Leaver Process- Atlassian Cloud Jira Service Management

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello

Can anyone help us with the necessary adjustments to the Atlassian Cloud Jira service desk connector?

We need the integration to not open a single card for all flat files during the leaver process.

This way, once an identity is deactivated, the connector should open a single card for each delimited file the identity has, instead of opening a single card for all delimited files.

Is there any documentation or step-by-step guide to adjust this?

Thanks

2

Hi @kazakeibic ,

You have many flat file sources ?

How you currently handle access during leaver process ? Do you remove access through Workflow or Sailpoint new revoke access feature through lifecyclestate ?

3

Hello Ousmane, Thanks in advance.

Unfortunately, yes, but we handle this with RPAs, for removal and granting.

During the leaver process, we operate in two ways (Remove All Access via LifeCycle State, and opening cards via the Service Desk Connector 1xN ).

The problem with opening only one card for all delimited sources is that the RPA’s removal logic doesn’t work very well.

And not only that, we need metrics and KPIs, such as faster access removal times.

And since only one card is opened for all delimited sources, this process makes these two fronts unfeasible, for example.

4

Hi @kazakeibic

When using Service Desk, you cannot directly create a single ticket for all sources because sources operate independently.

If the access profiles/entitlements belong to the same Role, then when removing this Role, all related access can be grouped into one provisioning plan, and a single ticket can be created. However, when revoking access profiles or entitlements from different sources, SailPoint will always create a separate ticket for each source.

In your use case, here’s a potential solution:

  1. Implement a custom workflow triggered during the Leaver process.

  2. Within that workflow, retrieve all entitlements for the user from the identified delimited sources.

  3. Create a single custom ticket that include all these entitlements by using an HTTP request and the Jira API.

  4. The ticket will not be directly linked to the SailPoint. However, the workflow can pause until the ticket is closed, and once closed, you can remove all relevant entitlements from the user or delete account by using the Sailpoint Accounts API.

  5. Exclude the removal of these delimited source accesses from your standard workflow to avoid duplicate actions.

Identified limitations of the proposed solution:

  • If you have an automatically assigned Role that includes at least one entitlement from these delimited sources, SailPoint will still create a revocation ticket once the user no longer meets the Role assignment criteria.

  • If another Role combines these delimited source entitlements with other access from different sources :

    • The solution becomes more complex. Removing such a Role would create a ticket.
    • If you do not revoke those Roles and delete the accounts from the delimited source, the next refresh will cause SailPoint to trigger a new account creation tickets.
    • To resolve you can modify Service Desk before provisioning to block Revoke Access actions based user current lifecyclestate.
5

Helllo Ousmane, thanks for the feedback.

But the main point is that I can’t continue creating just one ticket to remove all entitlements from delimited sources.

We need to “break” the option that, in the leaver process, opens one ticket for each delimited source, rather than a single ticket for all delimited sources.

Is this possible?

Regarding the option to remove all access, we’ll perform the revalidation on the delimited sources, but I thought this would make more sense for all sources.

Thanks again.