Hey folks, looking to see if anyone has tackled this specific integration. We're in the middle of a cloud identity consolidation project, moving off a messy on-prem AD setup, and JumpCloud is our chosen path. The goal is to have a single source of truth for user lifecycle.
A big piece for us is automating access to Jira Service Desk (JSD) projects based on team or role changes in JumpCloud. The manual request tickets are killing our IT service team. We want to trigger access provisioning/de-provisioning in JSD when a user's JumpCloud groups are updated.
I've been down the rabbit hole with their Workflows and the new OpenID Connect (OIDC) to SCIM app, but Jira's SCIM API is... finicky. Has anyone built a reliable bridge?
Some specific questions:
* Did you use the JumpCloud Workflows (powered by Tines) to call Jira's API directly, or did you go the SCIM route?
* Any major pitfalls with group synchronization? JSD seems to map groups to "organization" roles, and the mapping isn't always 1:1.
* How are you handling de-provisioning? Just removing the user from the JSD project, or fully deactivating their Jira account? We want to avoid the latter if they still need Confluence access.
Here's a snippet of the kind of Workflow API action we're prototyping for granting "Service Desk Team" access:
```json
{
"url": "https://your-domain.atlassian.net/rest/servicedeskapi/servicedesk/{{sd_id}}/organization",
"method": "POST",
"headers": {
"Authorization": "Basic {{base64_encoded_token}}",
"Accept": "application/json",
"Content-Type": "application/json"
},
"body": {
"accountId": "{{jira_account_id_from_scim}}"
}
}
```
The tricky part is reliably getting that `jira_account_id`. If you've made this work, I'd love to hear your playbook—or your horror stories. Did you eventually need a small middleware app to translate between the two systems?
test the migration twice
We went the direct API route with JumpCloud Workflows last year. The SCIM sync was too rigid for our JSD project mappings, and we needed more control over de-provisioning logic.
The main pitfall you mentioned is spot on: JSD flattens groups into "organization" level roles. We ended up creating a mapping table inside the workflow itself to translate one JumpCloud group to multiple JSD project roles when needed. It's a bit more maintenance, but it works.
For de-provisioning, we only remove the user from the specific JSD project, not deactivate the Atlassian account. The workflow checks if the user is in any other JumpCloud groups that map to Jira access before doing anything destructive. It's saved us from a few "why is my Confluence gone?" tickets.
terraform and chill