CASE STUDY · NONPROFIT & ASSOCIATIONS · INTEGRATION
Okta Integration Scales Onboarding at a Climate Risk Analytics Company
Identity operations built for a smaller team now scale with a workforce turning climate models into decision-grade data.
The Enterprise Challenge
Every new hire required manual IT steps to provision access, one application at a time.
The client, a climate risk analytics company, provides climate risk analytics to organizations that need to quantify and manage their exposure to climate events. Its scientists turn climate models into decision-grade data, and its clients use that data to plan around specific physical risks rather than react to them. The company runs on a modern, cloud-heavy toolchain: GitLab, Google Workspace, Snowflake, Salesforce, AWS, and more, with user authentication running through Okta.
Onboarding details lived in JIRA while authentication ran through Okta, and the two were not connected. Every new hire meant manual IT steps to provision the account, assign groups, and grant application access, and every departure meant chasing accounts to revoke. The company wanted the whole handoff automated, JIRA form to Okta enforcement: user provisioning, group assignments, application access, and terminations, all driven by selections made in the JIRA onboarding form.
The Solution
At a Glance
A climate risk analytics company’s identity operations, built for a much smaller team, still required manual IT steps to provision every new hire one application at a time. i3solutions integrated Okta so provisioning now triggers automatically from a JIRA form.
Provisioning now runs automatically from the JIRA form submission, Okta SSO covers more than a dozen applications with role-driven access, and new hires arrive with accounts, groups, and applications already live on day one instead of waiting for tools to catch up.
Strategic Trigger
Two Systems, Zero Connection, Every Hire
The gap was architectural: JIRA held the onboarding record and Okta enforced who could reach what, but nothing carried information from one to the other. Every hire, role change, and departure crossed that gap by hand, through IT tickets and checklists, with the usual results of manual identity work: delay on day one and lingering access on the way out.
The company decided the handoff should be automated from form to enforcement, with the JIRA form as the single point of entry driving everything downstream: user provisioning, group assignments based on roles and responsibilities, application access, and terminations.
Conditions That Triggered the Engagement
- Onboarding records in JIRA and authentication in Okta, with no connection between them
- Provisioning, group assignment, and application access handled through manual IT steps for every hire
- Terminations depending on someone remembering to chase and revoke each account
Every New Hire Shouldn't Require Manual IT Steps
This company automated onboarding provisioning without ripping out either of the two systems already in place. If IT is still manually provisioning every new hire in your organization, that’s usually an integration gap, not a systems replacement.
Stakes
Lingering Access Is a Security Hole
For a company whose product is data, access control is not an administrative nicety. Manual provisioning meant new employees waited for the tools their role required, and manual termination meant departed employees could hold access longer than they should, exactly the kind of path a breach exploits and an auditor flags.
The operational stake was IT capacity. Account maintenance is recurring, interrupt-driven work; every hour administrators spent provisioning accounts and adjusting permissions by hand was an hour not spent on projects, and the cost scaled with every hire.
Constraints and Complexity
One Form, More Than a Dozen Applications
The integration had to serve a genuinely diverse application estate. Single sign-on needed to extend across more than a dozen third-party applications, including GitLab, Google Workspace, Snowflake, Salesforce, Spinnaker, Prefect, and AWS, each with its own access semantics, and access had to stay aligned with regulatory requirements and internal security policy.
The design constraint was single entry. Employee credentials, department affiliations, access permissions, and hardware requirements all had to be captured once, in the JIRA form, and everything downstream had to read from that record, so that a role’s access profile was a mapping decision in a reference table rather than a per-hire judgment call.
Selection Rationale
Senior Microsoft Specialists with Proven Delivery Depth
The work sat squarely in identity and workflow engineering: modifying JIRA form capture, building a custom Okta workflow, and mapping roles to access through a maintainable reference table, then extending single sign-on across a heterogeneous application estate without breaking anyone’s working day.
The company engaged i3solutions, a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, delivered by an all-senior, all US-based delivery team, senior engineers who integrate identity platforms and line-of-business systems as a core discipline, whatever the vendor mix.
The Engagement Approach
i3solutions built the integration so the employee lifecycle, entry to exit, runs on one path: the JIRA form drives it, the reference table maps it, and Okta enforces it.
PHASE 01
Onboarding Data Capture Design
i3solutions made strategic modifications to the JIRA form so it collects what accurate provisioning needs: employee credentials, department affiliations, access permissions tied to roles and responsibilities, and hardware requirements, entered once.
PHASE 02
Okta Workflow and Reference Table Build
A custom workflow within Okta activates when the JIRA form is submitted. A reference table maps form selections to Okta groups, the user account is provisioned in the company’s environment, and email notifications tell stakeholders the account is live.
PHASE 03
Single Sign-On Across the Application Estate
i3solutions extended Okta single sign-on to more than a dozen third-party applications, including GitLab, Google Workspace, Snowflake, Salesforce, Spinnaker, Prefect, and AWS, so employees reach everything they are entitled to with one set of credentials.
PHASE 04
Lifecycle Automation for Changes and Terminations
Role changes updated in the JIRA form trigger the workflow, which reads the reference table and adjusts Okta group assignments to match the updated profile. Terminations initiated through the form deprovision access and revoke privileges immediately.
Technical Transformation
The integration connects the two systems the company already ran. JIRA is the project management system where onboarding starts: the customized form is the single point of entry for employee credentials, department affiliations, access permissions, and hardware requirements. Okta is the identity and access management platform that connects users to applications and data; the custom Okta workflow runs authentication and access management across the company’s technology environment. When the form is submitted, the workflow reads a reference table that maps selections to Okta groups, provisions the account without manual IT steps, and notifies stakeholders. Access permissions stay synced with employee profiles, so each person holds exactly the access their role and responsibilities call for, and access policies are enforced consistently across JIRA and every integrated application. The same integration extends Okta single sign-on to more than a dozen third-party applications, among them GitLab for DevOps, Google Workspace for productivity, Snowflake for data warehousing, Salesforce for CRM, Spinnaker and Prefect for delivery and workflow orchestration, and AWS for cloud infrastructure.
Measurable Outcomes
Onboarding, Automated End to End
Provisioning now triggers automatically from a JIRA form submission, with role-driven access replacing hand-by-hand grants.
| Outcome | Before | After |
|---|---|---|
| User provisioning | Manual IT steps for every hire | Automated from the JIRA form submission |
| Application access | Granted application by application, by hand | Role-driven through the reference table |
| Sign-on | Separate credentials per application | Okta SSO across more than a dozen applications |
| Terminations | Accounts chased and revoked manually | Deprovisioned immediately through the same workflow |
| Day-one readiness | Tools arriving after start | Accounts, groups, and applications live on day one |
| IT administrator time | Consumed by account maintenance | Spent on projects, with self-service covering routine requests |
User authentication and access management are centralized in Okta, cutting the risk of unauthorized access and narrowing the paths a breach could take. Employees reach their applications with a single set of credentials: less time managing logins, more time working. Provisioning and group assignments run automatically from the JIRA form, so new employees have their tools on day one and onboarding costs less in both time and effort.
User management runs automatically and self-service covers routine requests, so IT administrators spend their time on projects, not account maintenance. Access stays aligned with regulatory requirements and internal security policy across every integrated application.
[PENDING-CLIENT-QUOTE: Replace with approved direct or paraphrased statement from [role] at [organization type] before final publication. A missing client quote does not block publication but must be resolved within 30 days of go-live.]
[PENDING ATTRIBUTION]
[role], [organization type]
Who This Engagement Serves
This engagement is relevant for
- A company whose onboarding record and identity platform are separate systems bridged today by tickets and manual checklists
- An organization running Okta with a diverse SaaS estate, GitLab, Google Workspace, Snowflake, Salesforce, AWS and similar, that wants role-driven access from one form
- A security or compliance owner who needs terminations to revoke access immediately rather than when someone remembers
Less relevant for
- You are evaluating an HRIS-native onboarding suite rather than integrating the JIRA and Okta systems you already run
- You are a small team where accounts are few enough that manual provisioning is not yet a bottleneck or an audit risk
What This Engagement Established
Identity Automation Is a Solved Problem
The engagement established that the employee lifecycle, entry to exit, can run on one integration when the pieces are arranged correctly: a form that captures everything once, a reference table that turns role decisions into access mappings, and an identity platform that enforces the result. Nothing about the pattern is exotic, and it does not depend on ripping out either system; JIRA keeps holding the onboarding record, Okta keeps enforcing who can reach what, and the integration carries the information between them. For organizations still running onboarding and offboarding on tickets and manual checklists, this is a solved problem, and the same pattern extends across whatever application estate single sign-on needs to reach.
Frequently Asked Questions
It is an integration that turns the JIRA onboarding form into the single driver of identity across a company. In this engagement, a ticket created in JIRA starts the onboarding process; the customized form captures employee credentials, department affiliations, access permissions, and hardware requirements in one place. A custom Okta workflow reads each submission through a reference table and provisions the user account, assigns Okta groups based on role, grants application access, and notifies stakeholders, all without manual IT steps. The same path handles role changes and terminations, so the record entered once in JIRA governs a person’s access from their first day to their last.
In this engagement, i3solutions treated the integration as workflow design rather than tool installation. The work started with the JIRA form itself, strategically modified so it captures what accurate provisioning requires, then encoded the company’s role and access decisions into a reference table that maps form selections to Okta groups. That table is the maintainable heart of the system: access policy lives in one mapping, not in per-hire judgment calls. The custom Okta workflow executes what the table specifies, and single sign-on was extended across the company’s third-party applications so enforcement is consistent everywhere a credential reaches.
A custom workflow within Okta activates when the JIRA onboarding form is submitted. The workflow reads the submission through a reference table that maps form selections, role, department, access needs, to Okta groups. The user account is provisioned in the company’s environment, group memberships are assigned, application access follows from the groups, and email notifications tell stakeholders the account is live. Changes run through the same mechanism: a role change updated in the JIRA form triggers the workflow, which re-reads the reference table and adjusts group assignments so access matches the updated profile. A termination initiated through the form deprovisions access and revokes privileges immediately.
This engagement’s returns are operational. New employees have their tools on day one, because provisioning and group assignments run automatically from the JIRA form, and onboarding costs less in both time and effort. IT administrators spend their time on projects instead of account maintenance, with self-service covering routine requests. Security and compliance improve in kind: centralized authentication narrows the paths a breach could take, access stays aligned with regulatory requirements and internal policy, and terminations revoke privileges immediately instead of whenever accounts get chased. An organization sizing its own return should count manual provisioning hours per hire, the application count each hire touches, and the audit exposure of departed-employee access.
i3solutions is a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, with every engagement staffed by an all-senior, all US-based delivery team. Identity integration rewards that seniority because the work crosses vendor boundaries: this engagement connected JIRA and Okta and extended single sign-on across GitLab, Google Workspace, Snowflake, Salesforce, Spinnaker, Prefect, and AWS, each with its own access model. The delivered pattern, one form, one reference table, one workflow, now runs the client’s employee lifecycle end to end. A scoping conversation maps your identity stack, the integration points, the effort involved, and comparable engagements to reference when you build the internal case.
Yes. A role change updated in the JIRA form re-runs the Okta workflow, which adjusts group assignments and application access to match the new profile. A termination initiated through the same form deprovisions the account and revokes access promptly.
Day-to-day operation happens in the JIRA form your team already uses. The reference table defines how form selections map to Okta groups, so routine additions, changes, and terminations do not require custom development.
Related Insights
More From i3solutions
Related Engagements
Entry to Exit, on One Integration
A form, a reference table, and an identity platform working together is what closed this company’s onboarding gap end to end. We can talk through what a comparable integration would look like for your environment.
