Request a consultationEnquire

Global enterprise software company

Rebuilding the identity, access and SaaS foundation of a global organisation.

Halation’s founder owned the design and led delivery of the programme, from tenant assessment and configuration proposals through data remediation, lifecycle engineering, application migration, device access security and handover. The work connected four identity sources and established a consistent way to manage people and application access across the organisation.

Assessment and proposalsArchitecture and process designEngineering and migrationRollout and handover

Designed and led by Halation’s founder in a previous role, before Halation Systems.

Founder delivery · completed before Halation Systems
1,200
users in the FastPass rollout
4
identity sources
31
SCIM integrations migrated
200+
access request offerings

The starting point

Problems an IT team would recognise.

  • Spreadsheet based external onboarding

    Three of the four identity sources relied on an ageing Google Sheet process without adequate validation or review.

  • Missing user attributes

    Profiles were incomplete across the sources, so attribute driven groups and rule based access could not be trusted.

  • Sign in and provisioning spread across systems

    SailPoint handled provisioning, Duo handled sign in and the existing Okta tenant sat alongside them, each configured separately.

  • Manual administration

    Access changes, licence assignment and leaver handling depended on people doing the same work by hand.

  • Inconsistent device and access controls

    Authenticators, session rules and network zones needed a consistent policy model tied to managed devices.

The architecture

From fragmented processes to coordinated identity.

Four sources became two intake paths into one directory. Provisioning, sign in, device access and operations each have a clear place, and every connection has a purpose.

Before: identity inputs from UKG HRIS and three spreadsheet managed populations fed an estate where SailPoint provisioning, Duo sign in and the existing Okta tenant operated as separate parts, with downstream SaaS applications. After: two intake paths, the UKG HRIS feed and three Okta Access Requests forms available through Slack channels, pass through source specific mapping and lifecycle processing in Okta Workflows into Okta Universal Directory profiles and group based assignment, which drive SCIM provisioning and SAML or OIDC sign in to applications. A device access lane applies Okta Verify FastPass with device assurance and application policies on managed macOS and Windows devices. An operations lane sends Slack notifications, keeps workflow logs and feeds Splunk monitoring.

Before Fragmented processes

Identity inputsFour populations, three of them managed in a spreadsheet
UKG HRIS
Contractors (spreadsheet)
Partners (spreadsheet)
Other external identities (spreadsheet)
Separate parts of the estateConfigured and operated independently
SailPointProvisioning
DuoSign in
Okta tenantExisting configuration
Downstream
SaaS applicationsSign in and provisioning handled system by system

Components grouped by role. The precise legacy topology is not shown.

After Coordinated identity

IntakeTwo paths
UKG HRISEmployee records
Three Okta Access Requests formsRequested from Slack channels, with logging
OktaOrchestration, directory, assignment
Okta WorkflowsMapping, validation, duplicate checks, lifecycle
Universal DirectoryProfiles and reconciled attributes
Group based assignmentRules, push groups, licence groups
Applications
SCIM provisioning31 application integrations
SAML / OIDC sign inProgressive SSO migration
Device accessApplies at sign in
Okta Verify FastPass1,200 users, macOS and Windows
Device assurance and policiesSession, authenticator, application, network zones
Managed devicesKandji / Iru and Microsoft Intune
OperationsOperational events
Slack notificationsProgress, completion, issues
Workflow loggingRun history
SplunkAdministrative monitoring
Simplified representation of the delivered architecture.

How onboarding was engineered

Two intake paths, one set of rules.

Employees arrive through the HR record; everyone else arrives through a request form built for their population. Both end in the same directory with the same assignment logic. The diagram is a conceptual summary, not an exported production workflow.

Employee pre hire: the UKG record is mapped into Okta, Workflows monitors the lifecycle, restricted device setup access opens five days before the start date, and wider company access follows lifecycle and assignment rules from the start date. External identity request: the relevant Okta Access Requests form, raised from its Slack channel, collects source specific data, Workflows validates and normalises it, checks Universal Directory and the company domain table for duplicates, applies identity type email rules, obtains IT approval where required, creates the identity with downstream assignments and reports through Slack, logs and Splunk.

  1. UKG recordThe HR record and its mapped attributes are the source of truth for employees.
  2. Lifecycle monitoringOkta Workflows watches the record for pre hire, start, change and leave events.
  3. Restricted access, five days earlyOnboarding begins five days before the start date, limited to device setup rather than the company application estate.
  4. Company access from the start dateApplication access follows lifecycle state and group based assignment rules.

The planning and delivery behind the system

Seven stages, each with an objective and an operational reason.

  1. Domain change and dependency coordination

    Objective
    Move the Okta domain from the former company name to the new one before the wider migration.
    Work
    Planned a Saturday rollout, coordinated dependent SSO and SCIM integrations and checked continued operation afterwards.
    Why it mattered
    A clean domain before the migration meant every later integration was built once, against the right name.

  2. Tenant assessment, configuration proposal and rebuild

    Objective
    Bring the existing tenant into line with company requirements.
    Work
    Reviewed authenticators, password policies, general settings, network zones, device assurance and other tenant settings section by section, proposed the target configuration and implemented what was agreed.
    Why it mattered
    The proposal gave the organisation a written baseline to approve rather than settings changed ad hoc.

  3. Source redesign, data remediation and lifecycle engineering

    Objective
    Replace the spreadsheet process with structured intake and reliable profile data.
    Work
    Mapped UKG, built three Okta Access Requests forms, each available from a Slack channel with logging, backed by delegated workflows, reconciled attributes across all four sources and implemented onboarding, offboarding, account management and leaver data transfer.
    Why it mattered
    Rule based access only works when the underlying attributes are complete and consistent.

  4. SCIM migration, mappings and group based access

    Objective
    Bring provisioning under one platform.
    Work
    Migrated 31 SCIM integrations from SailPoint, rebuilt SailPoint transformations as Okta Expression Language in profile mappings, cleaned application mappings and reworked group based assignment, governance, push groups, administrative groups and licence groups. Re engineered the largest integration to remove manual steps.
    Why it mattered
    Centralised provisioning removed a second system to operate and simplified the logic the team had to understand.

  5. FastPass rollout and device and application policy configuration

    Objective
    Tie sign in to managed devices with policies suited to each application.
    Work
    Rolled out Okta Verify FastPass to 1,200 users on macOS and Windows, integrated with Kandji / Iru and Microsoft Intune, configured device assurance, authenticator, global session and application policies, grouped application SSO into four policy groupings and applied network zone restrictions for selected countries and VPN related access.
    Why it mattered
    Consistent policies replaced per application judgement calls and made the access model explainable.

  6. Bookmark continuity and progressive SSO migration

    Objective
    Move sign in without losing application discovery.
    Work
    Scripted the creation of 110 Okta application bookmarks from Duo, then migrated application SSO progressively using SAML and OIDC, with JIT account creation where applicable, consolidating onto the provisioning integrations already built.
    Why it mattered
    People kept finding their applications in one place while each integration moved on its own schedule.

  7. Further automation, documentation and operational handover

    Objective
    Leave an environment the operating team could run.
    Work
    Built more than 200 access request offerings with automated fulfilment and approvals where required, added licence review and account management automation, documented the environment and handed it over.
    Why it mattered
    The programme ended with the IT team, not the implementer, in control of day to day operation.

This plan is a reconstructed summary of the delivered work. It is not an original proposal, change record or project schedule.

Data remediation

Reliable automation started with the data.

Reliable access automation depended on fixing the underlying data first. Every later rule, group and integration was built on the reconciled profiles.

  1. Source recordsUKG and the three external populations
  2. Reconciliation and validationHistorical spreadsheets and other applications used to find missing values
  3. Profile mappingsMerged into Okta profiles; SailPoint transformations rebuilt as Okta Expression Language
  4. Usable attributesComplete, consistent profile data
  5. Rule based assignmentsDynamic groups and access rules that could be trusted

Design decisions

ProblemDecisionOperational benefit
One spreadsheet process served three different external populationsSource specific intake through three Okta Access Requests forms, raised from SlackEach population answers the questions that apply to it, so the data arrives usable
New starters needed a device before day one but not application accessRestricted pre hire access from five days before the start dateDevice setup happens early without early exposure of business applications
Duplicate identities across current and historical domainsDirectory and historical domain checks before creationOne identity per person regardless of naming history
Access assigned by handGroup based assignment driven by profile attributesAccess changes follow the record instead of a ticket queue
One policy did not suit every applicationApplication specific policy groupingsStronger controls where they matter without friction everywhere
A single cutover would have put every integration at risk at onceStaged migration with bookmark continuityEach integration moved on its own schedule while people kept working

Secure access with managed devices

Sign in tied to the device, with policies suited to each application.

The programme brought employee sign in onto managed devices and applied access policies suited to application requirements. FastPass reached 1,200 users across macOS and Windows work laptops, with device assurance checks and policies grouped by application rather than a single rule for everything.

An employee on a managed macOS or Windows device signs in with Okta Verify FastPass. Policy inputs, device assurance, authenticator policy, global session policy, application authentication policy and network zones, are evaluated together and the employee reaches the application. Device management through Kandji / Iru and Microsoft Intune and endpoint protection with CrowdStrike are supporting context.

EmployeeManaged macOS or Windows laptop
Okta Verify FastPassSign in from the managed device
Policy inputsEvaluated together
Device assuranceManaged device signals
Authenticator policyFastPass and enrolment rules
Global session policySession conditions
Application authentication policyFour groupings by application requirement
Network zonesSelected countries and VPN related access
ApplicationThe requested service
Application accessAccording to the application's policy grouping
Supporting contextDevice management and endpoint protection around the sign in
Kandji / IruMicrosoft IntuneCrowdStrike

What the operating team gained

Before, what changed, and the result.

BeforeWhat changedResult
Fragile external intakeStructured forms and controlled processingMore consistent onboarding
Incomplete profilesReconciled attributes and simpler mappingsA foundation for rule based access
Provisioning spread across the prior setup31 SCIM integrations migrated and reworkedCentralised application lifecycle administration in Okta for that scope
Repetitive access work200+ request offerings with automated fulfilment and approvalsLess routine manual administration
Little visibility of workflow runsSlack notifications, logging and SplunkProgress and issues visible to IT
Delivery knowledge held by the implementerDocumentation and handoverAn environment the operating team could manage
  • Delivered without reported service outages.
  • The work reduced licensing costs and manual administration.
Back to all programmes

Does your identity environment need this kind of rebuild?

If onboarding still depends on spreadsheets, access changes take too much manual work, or your identity tools are difficult to operate together, let’s discuss what needs to change.

Request a consultation