The Atlassian Friend #4: I Ended Up Building an Identity Layer.

[#1]

Last week I was implementing what initially looked like a very simple requirement.

In our case, the communication platform happened to be Slack.

The objective was straightforward: instead of sending a Jira Service Management approval reminder by email, we wanted approvers to receive a direct message through a Slack App.

At first glance, this looked like a simple API integration.

A Send Web Request action.
A JSON payload.
A Slack App.

Problem solved.

Or so I thought.

The problem wasn't the communication platform

The API integration itself turned out to be surprisingly simple.

The real question was:

Who am I sending this message to?

Slack needs a Slack User ID.
Jira knows an Atlassian Account ID.
Okta knows something different.

Every platform identifies the same employee differently.

At that moment I realized I wasn't trying to solve a communication platform problem.

I was trying to solve an identity problem.

Interestingly...

While implementing this integration, I was already working on something completely different.

For several weeks I had been looking for a reusable source of employee identity information that every Automation for Jira rule could consume.

Different automations required different attributes:
- Atlassian Account ID
- Slack User ID
- Okta ID
- Manager
- Department
- Location

I didn't want every automation solving identity independently.

Why Jira Assets?

One obvious question is:

Why not simply query Okta every time an automation runs?

Technically, I could.

Architecturally, I didn't think it was the right decision.

I'm already heavily invested in the Atlassian platform.

I wanted business automations to remain inside the Atlassian ecosystem instead of calling external systems every time they executed.

More importantly, I wanted to consolidate identity-related attributes into a single Employee object.

Okta remains the Source of Truth.

Jira Assets becomes the Shared Identity Context Layer.

Building the Employee object

Independent synchronization automations enrich an Employee object in Jira Assets using information from Okta and the Jira REST API.

The Employee object contains identity attributes such as:

• Atlassian Account ID
• Slack User ID
• Okta ID
• Manager
• Department
• Location
• Email
• Employment Status

Identity synchronization remains completely independent from business automations.

One Employee Object. One Lookup.

Automation for Jira performs a single Lookup Objects action using AQL.

Once the Employee object has been found, every synchronized attribute immediately becomes available.

One lookup.

Complete employee context.

Business automations don't need to understand where the information came from.

They simply consume it.

Identity first. Business action second

Once identity has been resolved, the original business problem becomes almost trivial.

In this implementation, the business action happened to be sending a direct message through Slack using a Send Web Request action.

Tomorrow exactly the same architecture could call:

• Microsoft Teams
• Workday
• ServiceNow
• Rovo
• Email
• Any REST API

Slack is simply the implementation example.

The architectural pattern is independent from the communication platform.

Final thoughts

Looking back...

I don't think I built an integration with a communication platform.

I built an identity layer that happened to solve a communication problem first.

Tomorrow it will probably solve something else.

Communication platforms will change.
APIs will change.
Business requirements will change.

The identity layer won't.

Antonio | The Atlassian Friend

[zoltanersek _outpostlabs_dev_]

nice write-up, really like the idea of treating identity as a shared infra piece, identity mapping across multiple systems can be a really tough challenge sometimes, and don't even get me started on Entra ID 😂