It is a way to copy an Okta group, and its members, into an app and keep the copy up to date.

Start with the words. Okta is an identity provider, a service that knows who your people are and tells your apps about them. A group is a named collection of people, such as “Sales Team.” An app here means any cloud service that your people sign in to, such as a chat service or a code-hosting site.

Group Push is a feature of Okta’s provisioning. Provisioning means creating and updating accounts in an app on your behalf. With Group Push, you pick an Okta group and tell Okta to push it to an app. Okta then creates a matching group in that app, or links to one that already exists, and adds the right members. When people join or leave the Okta group, Okta updates the app’s group to match.

Why this matters

Many apps decide what a person may do based on the app’s own groups. A code-hosting site may give a team write access to certain projects. A chat tool may place a team into private channels. If those groups are managed only inside the app, they slowly stop reflecting reality. Group Push lets Okta, which already knows who belongs where, control those app groups. Access then follows the one master source, and the app stays accurate without extra work.

A short glossary makes every later chapter easier to read.

Two sets of lists, kept by two sets of hands, always drift apart.

Without Group Push, access in apps is managed in two places. Okta knows that Maria is in Sales. The chat tool has its own idea of who is in the Sales channel. When Maria moves to Support, somebody must update Okta, and somebody must separately update the chat tool. Often the second step is forgotten. Maria stays in the Sales channel for months, reading conversations she no longer needs to see. This is not a rare slip. It is what happens whenever two lists are maintained independently. Each new app multiplies the problem. With ten apps, a team change means eleven edits, and every one of them is a chance to make a mistake or to forget.

One master, many copies

The core idea is simple: choose one master and let the others be copies. In identity work, Okta is usually the master for who belongs to which team. The apps are the copies. Group Push is the mechanism that keeps the copies faithful. It does not make decisions; it carries out the decisions already recorded in Okta.

These two features sound alike but do different jobs. Mixing them up is the most common beginner mistake.

Group assignment answers the question, “Which people are allowed to use this app?” When you assign a group to an app, every member of the group gets an account and can sign in. The group is only a convenient way of choosing people. The app itself may never learn that the group exists.

Group Push answers a different question: “Which groups and memberships should exist inside the app?” It creates or links a group in the app and keeps its members matched. The app can then use that group for its own decisions, such as channel access or project permissions.

A common and healthy combination

Many companies use both with the same Okta group. The group “Engineering” is assigned to the code-hosting app so that every engineer gets an account. The same group is pushed to the app so that a matching “Engineering” team exists there, and the app’s rules can give that team access to repositories. One group, two jobs, one master list.

A few simple parts work together. Seeing each one makes the whole feature easy to understand.

flowchart LR
  SRC["Group sources: HR, directory, Okta rules"] --> GRP["Okta groups and memberships"]
  GRP --> ASG["App assignment: who has an account"]
  GRP --> GP["Group Push configuration"]
  ASG --> CONN["Provisioning connector"]
  GP --> CONN
  CONN --> API["App API or SCIM endpoint"]
  API --> AG["Matching groups in the app"]
  AG --> PERM["App permissions, channels, teams"]
  CONN --> LOG["Okta System Log"]

What must be true for it to work

Group Push is available only for apps whose connection supports it. Not every app does. Provisioning must also be switched on for the app, and the connection must be authorized with enough rights to create and edit groups. If any of these is missing, the Push Groups tab either does not appear or the push fails. Before you plan around Group Push for an app, check that the app’s listing says it supports group management.

A pushed group is only as good as the group that feeds it.

Group Push copies whatever the Okta group contains. So the quality of the pushed group depends on how the Okta group is maintained. There are several ways an Okta group can be filled, and the choice matters.

Rule-based groups are the best match

The cleanest design pairs Group Push with group rules. A group rule places people in a group automatically when their profile matches a condition, such as department equals Sales. The group then changes whenever HR changes the profile, and Group Push carries that change into the app. The whole chain, from HR record to app group, runs without a human touch. This is the goal to aim for.

You can pick groups one at a time, or describe a pattern and let Okta pick them all.

Okta offers two styles for choosing which groups to push. In the first, you search for a specific group and add it. In the second, you create a rule based on the group’s name, and Okta pushes every group whose name fits the pattern. Okta describes these as pushing groups by name and pushing groups by rule, though the exact labels in your console may differ.

When you push a group, Okta must know whether to build a new matching group or to join an existing one.

When you add a group to Group Push, you generally choose between two paths. In the first, Okta creates a new group in the app, normally with the same name as the Okta group. In the second, Okta links the Okta group to a group that already exists in the app. After linking, the app group’s membership is managed from Okta.

Linking takes control

This is a point beginners often miss. When you link to an existing group, Okta becomes the master of its membership. Members that exist in the app group but not in the Okta group may be removed when the groups are matched, depending on the app and the settings. Before you link, compare the two lists, decide which is correct, and tidy them. Otherwise you may be surprised when people vanish from a group on the first push.

Naming matters

Because the new app group usually takes the Okta group’s name, a clear naming scheme pays off. A name like “APP-CodeHost-Engineering-Write” tells everyone what the group is for, in Okta and in the app. A name such as “Group 12” tells nobody anything, and months later no one dares to change it.

Behind the simple button, Okta carries out a short, orderly sequence.

sequenceDiagram
  participant Admin as Administrator
  participant Okta as Okta
  participant Conn as Provisioning connector
  participant App as App
  Admin->>Okta: Add group to Push Groups
  Okta->>Conn: Request group creation or link
  Conn->>App: Create or find the group
  App-->>Conn: Group identifier
  Okta->>Conn: Send list of members
  Conn->>App: Add members who have accounts
  App-->>Conn: Result for each member
  Conn-->>Okta: Success or errors
  Okta-->>Admin: Status shown on the Push Groups tab

Only people with accounts can be placed

Step three hides an important rule. Okta can place only those people who already have an account in the app. Someone who is in the Okta group but not assigned to the app has no account there, so they are skipped. If the person is later assigned, Okta can add them to the pushed group after their account is created. This ordering explains many “why is this person missing” questions.

After the first push, the real value is in the small updates that follow.

Once a group is being pushed, each change in the Okta group travels to the app. Understanding the typical cases helps you trust the system and predict its behavior.

Movers and the group rule chain

The most useful case is the mover. Priya moves from Support to Billing. HR updates her profile. A group rule removes her from the Support group and adds her to the Billing group. Group Push then removes her from the Support group in the app and adds her to the Billing group there. Nobody touched the app. Her permissions inside it changed within minutes, and the old team’s access is gone.

The status column is the quickest health check for any pushed group.

On the Push Groups tab, each group shows a status. The names below reflect what I know of the product; confirm the exact words in your console. Learning them lets you read the page at a glance.

Fixing errors without making them worse

When a group shows an error, resist the urge to delete and recreate it. Deleting can remove the app group and the permissions attached to it, and recreating can produce a duplicate with a new internal identifier. Instead, read the message, fix the root cause, and push again. If you truly must rebuild, note the app group’s permissions first, so you can restore them. Slow, careful repair almost always costs less than a quick rebuild that surprises everyone who relied on the group.

Reading an error

An error on a group usually has a short message from the app. Common messages say that a user was not found, that a group name already exists, or that the connection lacks permission. Each tells you where to look. “User not found” points to a missing assignment. “Name already exists” points to a duplicate group in the app. “Permission denied” points to the connection’s credentials or the account’s rights in the app.

What happens when the Okta group changes shape or goes away is worth deciding before it happens.

Groups live a long time, and their names and purposes change. When you rename an Okta group that is being pushed, the app group may or may not follow. Some apps rename their group when Okta sends the update. Others keep the old name, or create a second group. Before you rename a pushed group, test the behavior in a safe app, because a mismatch can break rules in the app that depend on the group’s name.

When you stop pushing a group

When you remove a group from Group Push, Okta commonly asks what to do with the matching group in the app. The typical options are to delete the app group, or to leave the app group in place but stop managing it. Each has consequences.

Moving a group between apps or organizations

Companies change tools. A team may stop using one chat service and start using another, or the identity team may move to a new Okta organization after a merger. In these moments, the same Okta group often needs to be pushed to a new app. Treat this as a fresh push, not a copy. Create or link the group in the new app, verify members, and grant permissions there. Keep the old push running until the move is complete, then stop it using the planned end-of-life steps. Rushing this transition is a common cause of duplicated groups and of access that lingers in the old app long after people have stopped using it.

Plan the end at the beginning

For each pushed group, write down what should happen at its end of life. Who decides it is obsolete? Does the app group get deleted or handed to someone? Which rules in the app depend on it? Having the answers in advance turns a risky clean-up into a calm routine.

Group Push is powerful, but it has edges, and knowing them saves surprises.

Some limits come from Okta, and others from the app. Always read both the Okta documentation and the app’s own notes. The points below are common patterns, not a guarantee for every app.

Differences between apps

Every app implements groups in its own way, and these differences shape how Group Push behaves. In one app, a group is a simple list of names with no further meaning, and permissions are granted to the group elsewhere. In another, a group is a team with its own settings, channels, and projects. In a third, groups may be limited to a maximum size, or limited to certain account types such as paid seats. Some apps allow a person in many groups, and others allow only one. Some remove a person from all groups when the account is disabled, while others keep stale entries until someone cleans them.

Because of this variety, keep a short profile for each app you connect. Write down whether it supports creating, linking, renaming, and deleting groups, what happens to members when the account is disabled, what name rules it has, and any size limits. Update the profile when you learn something new. Over time, this small library becomes the most useful guide your team owns, and it turns the surprises of one app into the knowledge for the next.

Seats, licenses, and costs

In many apps, an account costs money. Assigning an app to a large group creates many accounts, and a pushed group does not change that cost, but it can change how people are placed in paid tiers. Before you add a group, check whether the app counts every member as a paid seat, and who approves the spend. Pairing Group Push with a license group, filled only for people who truly need the paid tier, keeps costs under control and makes bills easy to explain.

Design around the limits

Because Okta groups are generally flat, design your groups to be flat too. Instead of building a tree of groups inside groups, create one group per real purpose, such as “CodeHost-Engineering-Write.” If a person needs two purposes, they belong to two groups. This is easier to push, easier to audit, and easier to explain.

Good Group Push starts long before the first push, with clear thinking about groups.

The most common failure of Group Push is not a technical fault. It is a messy set of groups. If the Okta groups are confusing, the pushed groups are confusing, and the apps inherit the mess. A little design work early saves a great deal of cleanup later.

Ownership and change control

Every pushed group needs two kinds of owner. A business owner decides why the group exists and who should belong to it, such as the head of the Payments team. A technical owner builds and maintains the group, its rule, and its push settings. Record both names in the group description. Keep a small change log with the date, the person, the reason, and any approval, especially for groups that grant sensitive power. When someone leaves the company or changes role, reassign their groups at once, because a group without a living owner is the first to drift.

Retiring and recycling groups

Groups tend to pile up. Projects end, teams merge, and tools are replaced, yet the groups remain. Schedule a review twice a year that lists every pushed group, its owner, its last membership change, and its purpose. Groups with no owner, no members, or no recent changes are candidates for retirement. Retire them through the planned steps: stop the push, decide the fate of the app group, remove the permissions the group held, and finally delete the Okta group. A tidy list of groups makes every later task faster and safer.

A simple naming scheme

Exact screens change over time, but the order of work stays the same.

A story shows how the pieces fit together on a normal working day.

Consider a company with three engineering teams: Payments, Search, and Mobile. They all use a code-hosting service that has its own teams. Repository access is decided by those app teams. The company wants engineers to receive the right access on their first day and lose it when they change teams, without the code-host administrator doing anything by hand.

The identity team builds three Okta groups with clear names: APP-CodeHost-Payments, APP-CodeHost-Search, and APP-CodeHost-Mobile. Each is filled by a group rule that reads the engineer’s department and team fields from HR. The code-hosting app is assigned to an umbrella group called All Engineers, so every engineer has an account. Then the three team groups are added to Group Push, and Okta creates three matching teams in the app.

The code-host administrator then grants each app team access to its own repositories, once. From now on, the flow runs by itself. When Anil joins the Payments team, HR records the team. The group rule places him in APP-CodeHost-Payments. Group Push adds him to the matching team in the code host, and he sees the Payments repositories the same day. When Anil moves to Search six months later, the rule moves him between groups. Group Push removes him from the Payments team and adds him to the Search team. His old repositories vanish from his view without a single ticket.

A second story shows how Group Push handles temporary people and linked groups.

A marketing agency uses a chat tool where teams and projects have private channels. The channel membership is decided by user groups inside the chat tool. In the past, the office manager added people to those groups by hand, and the lists were always wrong. Departed contractors stayed in project channels for months, and new colleagues complained they could not see important conversations.

The agency decides to link instead of create. The chat tool already has user groups named “Design,” “Strategy,” and “Clients-Acme.” The identity team compares each list against the real staff, tidies them, and links the three Okta groups to the existing app groups. The first push corrects the memberships: a handful of stale names disappear, and a few missing colleagues appear.

For contractors, the team adds a rule. Anyone with the worker type “contractor” and a project code joins a temporary group for that project, for example TEMP-Acme-Launch, which is also pushed to the chat tool. When the contractor’s end date arrives, a scheduled workflow deactivates their Okta account. Their app account is disabled, and their membership disappears from the project group. The project channel stays clean, and nobody has to remember.

A pushed group has a life, from the idea to the day it is retired.

flowchart TD
  A["Need: team requires access in an app"] --> B["Design: name, owner, rule"]
  B --> C["Okta group created and filled by rule"]
  C --> D["App assigned so members have accounts"]
  D --> E["Group added to Group Push"]
  E --> F["App group created or linked"]
  F --> G["Members pushed; permissions granted in app"]
  G --> H["Ongoing: joins and leaves flow automatically"]
  H --> I["Periodic review of purpose and members"]
  I --> J{"Still needed?"}
  J -->|"Yes"| H
  J -->|"No"| K["Retire: stop push, handle app group, delete Okta group"]

What flows and what does not

Group Push moves group names and memberships. It does not carry over the permissions you build around the group inside the app. Those stay in the app, where an app administrator sets them. This split is useful: Okta controls who is in the group, and the app controls what the group can do. Each side stays simple, and neither needs to know the other’s internal details.

Group Push can grant real power inside apps, so it deserves the same care as any access control.

When a group is pushed, its members may suddenly gain permissions in the app. That makes the control over groups and rules a security matter. If an attacker, or a careless administrator, can add themselves to a pushed group, they gain access across every app where that group is used.

Principles to follow

• Least privilege for people. Only a small set of administrators should be allowed to edit pushed groups, and fewer still should be allowed to create push rules.
• Least privilege for connections. Give the provisioning connection only the rights it needs, and store its secrets safely.
• Strong sign-in for administrators. Use phishing-resistant factors and fresh proof before sensitive changes.
• Protect privileged groups. Groups that grant administrator rights in apps need tighter rules, approvals, and alerts on every change.
• Separate duties. The person who requests access to a sensitive group should not be the one who approves it.
• Review regularly. Check who is in each pushed group and what the group can do in the app.

Who can do what: separating roles

Group Push touches several kinds of work, and they should not all belong to one person. One role designs and approves group names and purposes. Another role builds the rules that fill groups. A third role configures provisioning and Group Push on each app. A fourth role, inside the app, grants permissions to the pushed group. When these are separate, no single mistake or stolen account can create a powerful group, fill it, push it, and use it. Okta supports custom administrator roles and resource sets, which let you give each role only the groups or apps it truly needs. Names of these features change, so check the current documentation, but the principle stays the same.

Approval for sensitive groups

Not every group deserves the same process. A group that places people in an ordinary project channel can follow a light path. A group that grants administrator rights, access to customer data, or the power to approve payments should need a human decision each time someone joins. Combine Group Push with access requests so that a manager or an owner approves membership, and the approval is stored as evidence. Time limits help too: a person who needs administrator rights for a day should receive them for a day, and then lose them automatically, with the removal flowing to the app through the push.

Privacy and minimal sharing

Group Push sends names and memberships to the app. Group names can reveal sensitive facts, such as “Layoff-Planning-2026” or “Legal-Investigation.” Name groups carefully, because the app’s administrators will see the names. Where a group’s name itself is sensitive, avoid pushing it and use another way to control access.

Plan for the day a push fails, so it is a small problem and not a crisis.

Recovering from a bad push

Suppose a group rule was wrong for ten minutes and a hundred people were pushed into a powerful app group. The first step is to stop the damage, not to find the cause. Correct or disable the rule, so the wrong people leave the Okta group, and let the push carry the removal to the app. If the app is highly sensitive, also remove the powerful permissions from the app group for a short time. The second step is to check what those hundred people did during the window, by reading the app’s own audit log. The third step is to find the cause and add a safeguard, such as a preview of rule matches, an approval for rule changes, or an alert on large membership jumps. Write down what happened, because the next person will thank you.

Backups and documentation

Keep a simple record of every pushed group: its name, purpose, owner, the rule that fills it, the app it is pushed to, and what it grants in the app. If you ever have to rebuild a push after a mistake or after moving to a new Okta organization, this record is the map. A shared document or a spreadsheet is enough. The key is that it exists and that someone updates it whenever a group is added or retired.

Drift and the reconciliation habit

Even a healthy setup can drift. Someone may edit a pushed group directly in the app, adding a person who is not in the Okta group. Depending on the app and settings, Okta may or may not notice and correct the difference. The only dependable remedy is a regular comparison between the Okta group and the app group. A monthly check of important groups finds drift before an auditor does.

Small groups push in seconds. Very large changes take planning.

For a typical group of a few dozen people, a push finishes in moments. Problems appear at larger scales: thousands of members, hundreds of groups, or a mass change such as a reorganization that moves a whole department at once. Each membership change becomes a call to the app, and apps limit how many calls they accept in a given period. Okta also has limits. When many changes arrive together, they queue up, and the app slowly catches up.

Why pushes are not instant

People often expect a membership change to appear in the app the very second they click save. In practice, several steps sit between the click and the result. Okta must record the change, evaluate any rules, queue the update, send it to the app, wait for the app’s reply, and handle any retry. Each step takes a little time, and any of them can be slowed by load. Seconds to a few minutes is normal. Anything longer deserves a look at the status and the log. Explaining this in advance to app owners and managers prevents many needless tickets, because people stop assuming that a delay means a failure.

Choosing between many small groups and a few large ones

Both extremes have costs. Many tiny groups are precise but can become a maze that nobody can navigate. A few large groups are easy to count but hide different purposes under one name. A good middle path is to create one group for each distinct level of access in each app, such as read, write, and administrator, and then fill each group by rule from the facts that justify the access. This keeps the number of groups manageable, gives each group a clear meaning, and makes reviews short, because a reviewer can read the name and know what it grants.

Planning for big changes

• Schedule large reorganizations outside working hours or at a quiet time.
• Move people in batches rather than all at once, and watch the status after each batch.
• Tell people that access changes may take some minutes, so they do not panic.
• Keep groups purposeful. Many small groups are easier to push and review than a few giant ones with mixed purposes.
• Test with realistic numbers before relying on a new app for a large group.

A control you cannot see is a control you cannot trust.

Okta keeps a searchable record called the System Log. It records provisioning actions, group changes, membership changes, and administrator actions. Event names vary between releases, so search by group name, app name, user, and time when a specific name does not match. Look for events about group membership being added or removed, groups being pushed, and provisioning errors. Confirm the exact event types in the current documentation.

Alerts worth having

• A pushed group that enters an error state and stays there.
• A sudden large change in the size of a pushed group.
• Any change to groups that grant administrator rights in an app.
• Repeated provisioning failures for the same app.
• A new push rule or a change to an existing rule.
• Credentials for an app connection nearing expiry.

Send the logs to your security monitoring tool, so group changes can be viewed beside sign-in events and app logs. A person added to an admin group and then downloading data a minute later tells a story that none of the logs tells alone.

Group Push gives control, but it also takes some control away from the app.

Comparing the approaches

For most organizations, the best path is assignment for accounts plus Group Push by name for the few groups that matter, then moving to push-by-rule once naming is strict and reliable. Add governance reviews for groups that grant sensitive power.

A pattern is a habit that works. An anti-pattern is a habit that looks fine until it hurts.

Patterns that work

Anti-patterns to avoid

These habits separate a calm rollout from a stressful one.

Testing before and after launch

Treat every new pushed group like a small software release. Before launch, write test cases: add a person and confirm they appear in the app; remove them and confirm they leave; move them to another team and confirm both sides; rename the group in a safe app and note the result; and disable the connection briefly to see how the failure looks. After launch, repeat a short version of these tests whenever you change a rule, add a push rule, or upgrade the app. A few minutes of testing prevents the quiet failures that are hardest to see, where nothing seems broken and yet the wrong people hold access.

Training the people around the feature

Group Push changes who is allowed to do what. App administrators lose the habit of editing membership directly, managers learn that HR changes drive access, and identity teams take on more responsibility for group quality. Give each group a short briefing and a one-page guide. Explain the new flow with a simple picture, state the rule “membership is changed in Okta only,” and say where to ask for help. Teams that skip this step often see well-meaning administrators undo the system by hand.

A checklist before pushing a group

• Purpose: Can you state in one sentence what the group is for?
• Owner: Does a named person look after it?
• Members: Is the Okta group correct and filled by a reliable rule?
• Accounts: Is the app assigned to the same people?
• Link or create: Have you compared lists if linking?
• Permissions: Are the group’s powers in the app set and reviewed?
• Retirement: Do you know what happens when you stop pushing?

Mistakes seen again and again

These stories are illustrative, built from common patterns, to show the ideas at work.

Most problems come from a short list of causes. Check these first.

flowchart TD
  S["Person missing from app group"] --> Q1{"In the Okta group?"}
  Q1 -->|"No"| F1["Fix rule or profile data in Okta"]
  Q1 -->|"Yes"| Q2{"Has an account in the app?"}
  Q2 -->|"No"| F2["Assign the app, wait for account creation"]
  Q2 -->|"Yes"| Q3{"Group status healthy?"}
  Q3 -->|"No"| F3["Read the error and fix the cause"]
  Q3 -->|"Yes"| F4["Use Push Now and check the System Log"]

A repeatable troubleshooting routine

Group Push is one tool among several. Knowing the others helps you pick the right one.

Choosing the right tool: a short guide

• The app needs real groups it can reference at any time, for channels, shared folders, or project teams. Use Group Push.
• The app decides permissions only at sign-in and has no stored groups. Use group claims in the sign-in token.
• The app has a single simple permission model, and only account access matters. Use assignment alone.
• The membership itself needs a human decision. Add access requests and approvals on top of the group that is pushed.
• Extra steps must happen when membership changes, such as a notification or a ticket. Use a workflow in addition to the push.

Group Push versus group claims

Some apps do not want groups to be created inside them. Instead, they read a person’s group names from the sign-in message each time the person signs in, and decide permissions from that list. This approach uses group claims, which means including group names in the sign-in token. It has no stored copy in the app, so there is nothing to drift. The trade-off is that the app learns about groups only when the person signs in, so changes appear at the next sign-in rather than within minutes. Group Push is better when the app needs real groups it can reference at any time, such as for channels or shared projects.