Signing in proves who someone is. It does not make sure the app has a correct account for them. That second job needs its own solution.

Two different problems

Single sign-on solves the problem of passwords. A person proves themselves once to Okta, and Okta tells each app who they are. But before any app can welcome a person, it usually needs a record for them: an account with a name, an email, a role and some settings. Single sign-on does not build that record. Somebody, or something, must create it, keep it correct as the person changes, and close it when the person leaves.

This second problem is called provisioning. The word comes from “provide”. The company provides each person with the accounts they need. The opposite word, deprovisioning, means taking those accounts away.

What happens without automation

In a company without automatic provisioning, each app has its own administrator or its own spreadsheet. When a new hire starts, someone sends a request to every app owner. Some respond in an hour, some in three days. The new hire spends the first week waiting. When the person changes team, nobody remembers to update their title or remove their old access. When they leave, a checklist is sent around, and one or two apps are always forgotten. Months later, an audit finds former employees with active accounts in systems that hold customer data.

Three simple verbs describe everything an identity system needs to do to an account over its life.

Create

Create means making a new account in an app for a person who does not yet have one. Okta sends the app the facts it needs, such as name, email and role. The app builds the account and returns its own identifier for it. From that moment, the person can use the app, and Okta remembers which app account belongs to which Okta user.

Update

Update means changing an existing account when something about the person changes. Maybe they were promoted and their title changed. Maybe they moved to another office and their location changed. Maybe they got married and their last name changed. Okta notices the change in the central profile and sends the new values to each app that stores them.

Deactivate

Deactivate means switching an account off, so the person can no longer use it, while usually keeping the account’s data in the app. It happens when a person leaves the company, when they lose access to the app, or when an administrator decides so. Deactivation is the safe, reversible way to remove access. Deleting an account is a different and more drastic step, which we cover later.

Joiner, mover, leaver

These three verbs line up with the three life events. A joiner triggers create. A mover triggers update, and sometimes also creates and deactivates, because a new team may bring different apps. A leaver triggers deactivate across every app at once. Designing provisioning means deciding, for each event, what should happen in each app.

Okta treats itself as the source of truth for who people are, and treats each app as a place that must match.

Inside Okta, every person has one central profile in the Universal Directory, Okta’s list of people and their facts. Every app that Okta provisions gets its own separate record of that person, called the app user. The app user is Okta’s note about the person’s account in that specific app. It holds the app-specific facts, such as the app username and the app’s own identifier for the person, plus a status that says whether the account is working.

Two directions

Provisioning in Okta can flow in two directions, and each direction is switched on separately in the app’s settings.

The settings on the Provisioning tab

When an app supports provisioning, its page in the Admin Console shows a Provisioning tab. In the “to app” direction, the tab typically offers a short list of switches that correspond to the three core actions.

• Create Users. When a person is assigned to the app, Okta creates their account in the app.
• Update User Attributes. When a mapped profile fact changes in Okta, Okta sends the new value to the app.
• Deactivate Users. When a person is unassigned from the app, or deactivated in Okta, Okta switches off their account in the app.
• Sync Password. For some apps, Okta can also keep a password in step. This is an optional extra, and often avoided where single sign-on is in use.

The exact names and available switches depend on the app and on the Okta version. Some apps offer only some of the actions, depending on what the app itself supports.

Provisioning through Okta is one of several ways to create accounts. Seeing them together shows when each one fits.

Reading the table in plain words

Manual work is fine for tiny teams. Bulk import is good for a one-time move. Just-in-time creation, which builds the account when a person first logs in, is quick but it never closes accounts. The method in this guide, in which Okta itself calls the app to create, update and deactivate, is the only common method that covers the whole life of an account automatically. A custom workflow can do the same job for apps that lack a standard interface, but you must build and maintain it.

Eighteen small words carry most of the meaning in this topic. Learn them once and every Okta provisioning screen becomes easier to read.

Provisioning involves a source of people, Okta’s engine, a connector, and the app itself, each with a clear job.

The architecture looks like a delivery chain. At the start is the place where facts about people first appear. In the middle is Okta, which collects, combines and decides. At the end is the app, which receives instructions and changes its own records. Between them, a connector translates Okta’s decisions into the language the app understands.

flowchart LR
    SRC["Source of people: HR system or directory"] --> UD["Okta Universal Directory"]
    UD --> GR["Groups and group rules"]
    GR --> AS["App assignments"]
    AS --> ENG["Okta provisioning engine"]
    UD --> MAP["Attribute mappings"]
    MAP --> ENG
    ENG --> CON["Connector: SCIM or native integration"]
    CON --> APP["Application accounts"]
    APP --> CON
    CON --> ENG
    ENG --> AU["App user records and status"]
    ENG --> LOG["System Log"]
    ENG --> TSK["Tasks for failed jobs"]
    

The parts, one by one

The source of people. Many companies keep the original list of employees in an HR system or a directory. Okta imports from it, so the facts start in a trusted place.

Universal Directory. Okta’s central list. Each person has one profile here. Provisioning copies selected facts from this profile into app accounts.

Groups and rules. Groups collect people by team, role or place, and rules fill the groups automatically from profile facts. Groups are the usual way to decide who gets which apps.

App assignments. Assigning a group to an app tells Okta that every member should have an account there.

Attribute mappings. The rules that decide which profile facts are sent and how they are named and shaped for the app.

The provisioning engine. The part of Okta that watches for changes, decides what must be created, updated or deactivated, queues the jobs and records the results.

The connector. It turns each decision into a web request that the app understands, and reads the app’s reply. Where the app supports SCIM, this is a standard connector. Otherwise it may be a built-in integration made for that specific app.

The app user record. Okta stores the app account’s identifier and status, so that later updates and deactivations are sent to the right account.

Tasks and the System Log. Failures appear as tasks that an administrator can retry, and every attempt is recorded in the log.

SCIM is the most common way Okta talks to apps. Understanding it makes every provisioning message easier to read.

SCIM stands for System for Cross-domain Identity Management. It is a pair of public standards, numbered RFC 7643 and RFC 7644, that describe two things: what a user record should look like, and what web requests may be used to create, read, change and remove such records. Before SCIM, each app had its own private way of doing this, and every integration was custom work. With SCIM, an app that follows the standard can be provisioned by any identity system that also follows it.

Web requests in simple terms

An app that supports SCIM publishes a web address, often ending with the word “Users”. The identity system sends requests to this address, using a few common request types. Here is how they match the three actions.

How deactivate works in SCIM

A SCIM user record has a field called “active”. It is true when the account works and false when it does not. When Okta deactivates an account, it normally sends a change that sets this field to false. The app keeps the record and its data, but blocks use. This is why deactivation is reversible: Okta can later set the field back to true.

The shape of a user record

A SCIM user record contains a few standard fields, such as a username, a name made of given and family parts, a list of emails, and the active flag. It can also carry extension fields for company-specific facts. Because the shape is standard, mapping between Okta’s profile and the app’s record becomes a matter of matching field names.

Authentication between Okta and the app

The app must know that requests really come from Okta. SCIM connections therefore use a credential, most often a long secret token that Okta presents with each request, or an OAuth-based credential that expires and is renewed. Keep these credentials safe, since anyone holding one can create and delete accounts.

Creating an account looks like one step, but Okta actually performs several small checks to avoid mistakes and duplicates.

sequenceDiagram
    participant A as Administrator or Group Rule
    participant O as Okta Engine
    participant C as Connector
    participant P as Application
    A->>O: Assign the person to the app
    O->>O: Build the app profile from the mappings
    O->>C: Ask whether a matching user exists
    C->>P: Search for the username
    P-->>C: No match found
    C->>P: Create the user with the mapped attributes
    P-->>C: Success with the app's own identifier
    C-->>O: Report success
    O->>O: Save the app user with its identifier and status
    

What the app does with the request

The app checks that required facts are present and valid, makes sure the username is unique, applies its own rules, such as license limits, and then creates the record. Some apps also send the new person a welcome email. Others place the account in a “pending” state until the person signs in for the first time. Know how your app behaves, so that the first-day experience is what you expect.

Most companies turn on provisioning for apps that already have users. Matching decides whether those people are recognized or duplicated.

Imagine an app with two hundred existing accounts that were created by hand over several years. You now switch on Okta provisioning and assign everyone. If Okta cannot recognize the old accounts, it creates two hundred new ones, or fails with errors, because the usernames are already taken. To avoid that, Okta compares the person’s profile with the app’s accounts, using one value as the match key, usually the username or email.

Two ways to bring old accounts under Okta’s control

• Match during create. When Okta is about to create an account, it searches for an existing one with the same key, and links to it if found.
• Import from the app first. Okta imports the app’s existing users into a staging list, matches each one to an Okta user using rules you set, and asks an administrator to confirm. Only confirmed matches are linked.

Why exactness matters

Matching is usually exact. A difference as small as a capital letter, a missing dot or a different email domain can make a match fail. For example, “sam.lee@example.com” and “samlee@example.com” look like two different people. Before a big rollout, export the app’s user list and compare it with Okta’s. Fix mismatches in advance, either in Okta or in the app.

A mapping is a simple rule saying “this box in Okta feeds that box in the app”. Good mappings are the quiet heart of good provisioning.

Okta’s profile and the app’s profile are two different forms with different box names. The Okta form may say “department” and the app’s form may say “dept”. A mapping connects them. In the Profile Editor, each app has a mapping screen with two directions. The “Okta to App” mapping controls what Okta pushes out. The “App to Okta” mapping controls what Okta pulls in during imports.

Kinds of mapping

When a mapping applies

Each mapping has a setting for when it is used. One choice is “create and update”, which means the value is sent when the account is first made and again whenever it changes in Okta. Another choice is “create only”, which sends the value once, when the account is first made, and leaves it alone afterwards. Create-only is useful for facts that the app owner will edit later, such as a preferred display name or a local role.

Who is the master of a fact?

For each fact, one system should be the master, which means its value wins. If Okta is the master of job title, the app’s title is overwritten at every update. If the app is the master, Okta imports the value instead. Two masters for one fact cause a tug of war in which each side keeps overwriting the other. Decide who is the master for each field, and map in only one direction.

People change all the time. Updates make sure each app keeps up without anyone remembering to type the change in twenty places.

flowchart TD
    A["A profile fact changes in Okta"] --> B{"Is the fact mapped to this app?"}
    B -->|"No"| X["No action for this app"]
    B -->|"Yes"| C{"Is Update User Attributes switched on?"}
    C -->|"No"| X
    C -->|"Yes"| D{"Is the mapping set to create and update?"}
    D -->|"No"| X
    D -->|"Yes"| E["Okta builds the new value from the mapping"]
    E --> F["Connector sends the change to the app"]
    F --> G{"Did the app accept it?"}
    G -->|"Yes"| H["Status stays active and the log records success"]
    G -->|"No"| I["A task appears with the reason"]
    

What triggers an update

An update starts whenever a mapped fact changes in the Okta profile. The change may come from an administrator editing the profile, from an HR system that Okta imports from, from a directory sync, or from the person themselves if you allow self-editing of certain fields. Okta compares old and new values, and only sends changes to apps that actually map the changed fact.

Changes that move people between apps

Some updates have a bigger effect than just a corrected value. If a person moves from Sales to Finance, a group rule may remove them from the Sales group and add them to the Finance group. Apps assigned only to the Sales group are then unassigned, which triggers deactivation there. Apps assigned to the Finance group are newly assigned, which triggers creation there. A single department change can therefore cause updates, creates and deactivations at the same time.

Updates that do not stick

If you see an update sent successfully but the value in the app keeps changing back, an app owner or another integration is probably overwriting it. That means two masters exist for the fact. Settle who is in charge and map the fact in only one direction.

Closing accounts is the most important action for security, and the one most often handled badly. This chapter explains what really happens.

flowchart TD
    S["Reason to remove access"] --> R1{"Which reason?"}
    R1 -->|"Person unassigned from the app"| D1["Okta marks the app user for deactivation"]
    R1 -->|"Okta user deactivated"| D1
    R1 -->|"Group membership lost"| D1
    D1 --> Q{"Is Deactivate Users switched on?"}
    Q -->|"No"| N["Account stays active in the app. Manual cleanup needed"]
    Q -->|"Yes"| E["Connector tells the app to switch off the account"]
    E --> F{"Did the app confirm?"}
    F -->|"Yes"| G["App user status becomes deprovisioned"]
    F -->|"No"| H["A task appears with the reason"]
    

What causes deactivation

• Unassigning a person from the app. If an administrator removes the assignment, Okta deactivates the account in the app.
• Losing a group. If the person leaves the only group that gave them the app, they are no longer assigned, and the same thing follows.
• Deactivating the Okta user. When a person leaves the company and their Okta user is deactivated, Okta deactivates their accounts in every provisioned app.

Deactivate versus delete

Beginners often mix these. Deactivate switches the account off but keeps it, with its data, in the app. Delete removes it completely. Okta’s usual behavior for leavers is to deactivate, not delete, because deactivation is reversible and keeps records that audits and handover work may need. Deletion, if wanted, is usually done later in the app itself, or through a separate process, after any retention period passes.

Things deactivation does not do

• It may not end live sessions. A person already signed in to the app may stay signed in until the session expires.
• It may not free the license. Some apps still count a deactivated account toward the paid seats until it is deleted or its license is removed.
• It does not transfer work. Files, tickets and projects owned by the person stay with the deactivated account unless someone reassigns them.
• It does not touch other sign-in paths. Saved passwords, access tokens and keys created inside the app may still work.

Creating an account is only half the story. People also need the right role inside the app, and that role must be kept correct.

Assignment by group

The cleanest way to decide who gets an account is to assign apps to groups, not to individuals. Group rules place people in groups from their profile facts, so that a new person in the Sales department appears in the Sales group automatically. The Sales group is assigned to the sales apps, so provisioning creates the accounts. When the person leaves Sales, the opposite happens.

Roles inside the app

Many apps have their own roles, such as viewer, editor and admin. Okta can send a role as part of the create or update. There are three common patterns.

• A fixed default role. Every new account starts with the lowest role. Extra rights are given inside the app, or through a separate request process.
• A role chosen from a profile fact. The mapping turns a fact, such as job level, into a role. Use with caution, and only with facts that people cannot edit themselves.
• A role chosen by assignment. Some connectors let you pick a role at assignment time, so different groups bring different roles.

Push Groups

Some apps have groups of their own, used to give permissions to many people at once. Okta’s Push Groups feature creates a matching group in the app and keeps its members in step with an Okta group. When someone joins the Okta group, they are added to the app’s group, and when they leave, they are removed. This lets the app’s permissions follow Okta’s group structure, with no manual work in the app.

Each person’s account in each app moves through states. Knowing them helps you read the Admin Console and find stuck accounts.

flowchart LR
    NA["Not assigned"] -->|"Assign"| PE["Pending"]
    PE -->|"Create succeeds"| AC["Active"]
    PE -->|"Create fails"| ER["Error"]
    ER -->|"Fix and retry"| PE
    AC -->|"Profile change"| UP["Update sent"]
    UP --> AC
    AC -->|"Unassign or user deactivated"| DE["Deprovisioned"]
    DE -->|"Assign again"| PE
    

Reading a stuck account

A person who sits in the pending or error state for a long time needs attention. Open the app user record, read the last message, and look for a pattern. If one account is stuck, the cause is usually specific to that person, such as a duplicate username. If many accounts are stuck at once, the cause is usually shared, such as an expired credential or an app outage.

Here is a complete route from an app with no provisioning to one where create, update and deactivate all run on their own. Labels differ slightly between apps.

Provisioning is not only pushing. Sometimes Okta must also listen, to learn about accounts that already exist in an app.

The “to Okta” direction brings information from the app into Okta. It has two main uses. The first is the user import, a one-time or scheduled read of all users in the app, used to find and match existing accounts. The second is profile updates from the app, in which certain facts that the app owns flow back into Okta’s profile.

How an import works

• Okta asks the app for its list of users. The connector reads the list in pages, so it can handle large apps.
• Okta tries to match each app user to an Okta user. Matching rules compare fields, such as username or email.
• Okta shows the result for confirmation. Clear matches are listed, unmatched users are shown, and conflicts are flagged.
• An administrator confirms. Confirmed matches become linked app users that Okta now manages.

When to use it

Use a first import whenever you move an app that already has users under Okta’s control. Use scheduled imports only for facts that the app truly owns. For most companies, Okta is the master of identity, so imports are mainly a clean-up tool at the start, and not a daily process.

Not every app supports the same thing. A short decision path helps you choose a method without guessing.

flowchart TD
    A["App needs automatic accounts"] --> B{"Does Okta have a ready connector for it?"}
    B -->|"Yes"| C["Use the connector and map attributes"]
    B -->|"No"| D{"Does the app support SCIM?"}
    D -->|"Yes"| E["Use a generic SCIM connection"]
    D -->|"No"| F{"Does the app have any web interface for users?"}
    F -->|"Yes"| G["Build a workflow or custom integration"]
    F -->|"No"| H{"Does it support just-in-time creation at login?"}
    H -->|"Yes"| I["Use just-in-time and add a review for leavers"]
    H -->|"No"| J["Manual process with a documented checklist"]
    

Reading the path

The path runs from the strongest, most automatic option to the weakest. A ready connector is the best, since it already knows the app’s rules. A generic SCIM connection is next. A custom workflow works when the app has some interface but not a standard one. Just-in-time creation is a partial answer that handles creation only. A manual checklist is the last resort, and it needs an owner who runs it on every joiner, mover and leaver.

Provisioning is not instant magic. It is a queue of small jobs, sent to apps that have their own speed limits and moods.

Queues and order

When many people change at once, Okta places the work into a queue and sends jobs to each app at a measured pace. Jobs for the same person are kept in order, so that a create happens before an update. Jobs for different people may run in parallel. In normal conditions, a single change reaches the app in seconds. After a large change, such as assigning a big group, the queue may take minutes or hours to clear.

Rate limits

Most apps limit how many requests they accept in a given time, to protect themselves from overload. When Okta sends too many, the app replies “slow down”, and Okta waits and tries again. This is normal during large rollouts and is the main reason for staged assignment. A huge wave of assignments does not fail, but it can be slow and can use up the app’s allowance, which might block other tools that use the same quota.

Retries and idempotence

If a request fails for a temporary reason, such as a network blip, Okta retries it after a delay. A well-built connector is careful that repeating a request does not cause harm: creating the same user twice should not make two accounts. That safety is called idempotence. It is the reason Okta checks for an existing user before it creates one.

Typical response codes

Provisioning holds the keys to every app’s user list. If that power is misused or stolen, an attacker can create accounts, change roles or lock people out. This chapter shows how to protect it.

Think about what provisioning can do. It can create accounts, write profile facts, set roles and switch accounts off, all without any person clicking inside the app. That is exactly what makes it useful, and exactly what makes it a target. The connection between Okta and each app is therefore a high-value path and deserves the same care as an administrator login.

The main risks

The protections

• Least privilege for the service account. Give the token only the rights needed to create, read, update and deactivate users. Do not use a personal super-admin login, which would also break when that person leaves.
• Secure storage and rotation. Keep secrets only where Okta stores them. Rotate on a schedule, and immediately after any suspicion or after an administrator leaves.
• Restrict where the credential works. If the app allows it, limit the token to Okta’s network addresses.
• Small, named owners. Each app integration has a named owner who reviews settings on a schedule.
• Protect Okta administrators. Require strong sign-in for anyone who can change assignments or mappings, and give each person only the administrator role they need.
• Review mappings for risk. Make sure no self-editable fact decides a role.
• Hunt for orphans. Regularly compare the app’s user list against Okta’s, and handle accounts that Okta does not know about.
• Alert on sensitive events. Raise alerts when a provisioning credential changes, a mapping changes, or an admin role is assigned.

flowchart LR
    ADM["Okta administrator"] -->|"changes assignments and mappings"| OK["Okta provisioning engine"]
    OK -->|"uses stored credential"| APP["Application user store"]
    ATT["Attacker"] -.->|"steals credential"| APP
    ATT -.->|"phishes an administrator"| ADM
    OK --> LOG["System Log and alerts"]
    APP --> AUD["App audit trail"]
    LOG --> SEC["Security team review"]
    AUD --> SEC
    

Reading the picture

The solid lines show the normal flow: an administrator changes settings, Okta uses its stored credential, and the app’s user store changes. The dotted lines show where attackers aim. One goes straight to the app using a stolen credential. The other goes through an administrator, using phishing. Both leave traces in the logs, which is why the log arrows to the security team matter as much as the prevention.

Provisioning runs quietly in the background, so you need ways to see what it did and to find out quickly when it did not work.

Where to look

A calm way to troubleshoot

Common problems and their usual causes

Joiner, mover and leaver as a daily routine

Every provisioning decision fits one of three moments in a person’s working life. A joiner is someone new, who needs working accounts on the first morning. A mover is someone who changes team, title or place, who needs some accounts added, some changed and some removed. A leaver is someone who departs, who needs every account switched off promptly. Teams that design for all three moments, and not only for joiners, avoid the most common gap: a company that is excellent at welcoming people and poor at closing the door behind them.

Movers deserve special attention because they are the quiet source of excess access. A person who changes teams three times without losing old access ends up with the combined rights of every team they ever joined. Rule-driven groups fix this automatically, since leaving a group removes what the group granted. Without them, someone must remember to clean up, and people rarely remember.

Questions to ask before you switch provisioning on

• Who owns the app? A named person must be able to say who should have access and in which role.
• What is the source of truth? Decide whether HR, a directory or Okta itself holds the correct facts.
• What happens to data when an account is closed? Agree whether files are transferred, kept or deleted, and who does it.
• How will we know it failed? Choose who watches tasks, and which alerts reach them.
• How do we undo it? Know how to stop provisioning, or restore a wrongly deactivated account, before it is needed.

Answering these questions takes an hour and prevents weeks of confusion. They also create the short document that auditors will ask for later, saying who approved access to the app, why, and how it is reviewed.

Provisioning is very valuable, but it is not free. A fair view lists both sides.

Trade-offs to decide on purpose

Teams that run provisioning well tend to repeat the same habits. Teams that struggle tend to repeat the same mistakes.

Good patterns

Anti-patterns to avoid

A short checklist

• Does each provisioned app have a named owner and a documented setup?
• Are Create, Update and Deactivate all tested and switched on?
• Is the service account limited to user management?
• Is every field mapped in only one direction?
• Do group rules, not people, decide assignments?
• Is someone reading the tasks page daily?
• Is there a regular check for orphan accounts?

A company of fifty people and a company of fifty thousand both need provisioning, but the second needs more care about volume and failure.

Scale: many people, many apps

The total work grows with the number of people times the number of apps. A company with ten thousand people and thirty apps may handle hundreds of thousands of accounts. Most of the time, changes arrive slowly and steadily, which is easy. The pressure comes in bursts: a merger, a yearly reorganization, a large hiring wave or a new app being rolled out to everyone.

• Use group rules. They scale because one rule decides thousands of assignments.
• Stage big changes. Spread large moves over hours or days, outside peak work times.
• Keep mappings lean. Fewer mapped fields mean smaller messages and fewer failure points.
• Know each app’s limits. Note the request rate allowed and plan large waves around it.

Availability: when something is down

Two systems must be healthy for a change to land: Okta and the app. If the app is down, Okta keeps the work waiting and retries, and the account appears when the app returns. If the app is down for long, tasks may show errors, and an administrator can retry them afterwards. The main danger is not the delay but the missed deactivation, so after an outage check that leavers were switched off.

sequenceDiagram
    participant H as HR System
    participant O as Okta
    participant A as Application
    H->>O: Bulk change for many people
    O->>O: Queue jobs per app and per person
    O->>A: Send first batch
    A-->>O: Too many requests, slow down
    O->>O: Wait and keep jobs in order
    O->>A: Send next batch slowly
    A-->>O: Accepted
    O->>O: Record results and list failures as tasks
    

Reading the picture

The HR system sends one large change. Okta does not push it all at once. It queues the work and sends a first batch. The app answers that it is too busy, so Okta waits and then sends the next batch more slowly. When the app accepts, the results are recorded, and any failures become tasks. The result is slower than a single instant push, but it is safe and complete.

To make everything concrete, follow one fictional employee, Priya, through her whole time at a company called Northwind Retail.

What the company never had to do

In six years, nobody had to create or close an account by hand. The help desk received no ticket on her first day, no ticket about her new name and no ticket about her transfer. At her exit, there was no hurried list of apps to check, and no forgotten account remained. The work was done by rules written once and checked regularly.

Lessons from the story

Priya’s story shows three habits that make provisioning work. First, every change started from a trusted record, HR, and not from a request to the help desk. Second, access followed group membership, so movement between teams was handled by removing and adding, and not by remembering. Third, deactivation was treated as seriously as creation, with a person confirming it in the log. If any of these three habits is missing, the story ends differently: a former employee with a live account, a long-time employee with rights from four old jobs, or a new starter waiting three days for a login.

Notice also what the company decided in advance. It decided that usernames never change, so that apps could always find Priya’s account. It decided that new accounts get the lowest role, so a mistake costs little. It decided that her files must be reassigned by a manager before deactivation, because the tool cannot guess who should inherit her work. Each decision is small, and each saves a painful discovery later.

Different organizations use the same three actions in different ways. These short pictures show common situations.

Short answers to the questions beginners ask most.

App provisioning keeps accounts in step with real people: created when they join, updated when they change and deactivated when they leave.

Okta does this by treating assignment as the trigger. When a person is assigned to an app, directly or through a group, Okta creates an account. When a mapped fact changes, Okta updates it. When the person is unassigned or their Okta user is deactivated, Okta switches the account off. The connection to the app is usually SCIM or a ready connector, with mappings that say which fact goes where. Good results depend on clean data, one master per fact, a safe low default role, careful credentials, staged rollouts and steady monitoring.