Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 83 additions & 0 deletions product/admin/push-rules.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
---
title: Push rules
og:title: Push rules - ConductorOne docs
og:description: Automatically sync user attributes from ConductorOne to connected systems.
description: Automatically sync user attributes from ConductorOne to connected systems.
sidebarTitle: Push rules
---
{/* Editor Refresh: 2026-01-29 */}

# Push rules

Push rules automatically sync user attributes from ConductorOne to your connected systems, keeping user information consistent across all your apps.

With push rules, you can control which attributes to sync and how values map to each connector. You can pull values directly from directory attributes or write custom expressions to transform data before syncing.

## Supported connectors

Push rules are currently available for:

- Active Directory
- Microsoft Entra

Check warning on line 21 in product/admin/push-rules.mdx

View check run for this annotation

Mintlify / Mintlify Validation (conductorone) - vale-spellcheck

product/admin/push-rules.mdx#L21

Did you really mean 'Entra'?

Each connector reports its own supported schema and whether it supports custom attributes.

## Create a push rule

You can create one push rule per connector to avoid conflicts.

1. [Navigation path to be added]
2. Select the connector you want to configure
3. [Additional steps to be added]
Comment on lines +29 to +31
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Incomplete placeholder content.

The navigation path and additional steps need to be filled in before this documentation is ready for publication.

Would you like me to help draft these steps once the UI workflow is finalized?

🤖 Prompt for AI Agents
In `@product/admin/push-rules.mdx` around lines 29 - 31, The document
push-rules.mdx contains placeholder lines ("[Navigation path to be added]" and
"[Additional steps to be added]") that must be replaced with the actual UI
navigation and concrete configuration steps; update the content in
product/admin/push-rules.mdx to (1) insert the full navigation path users should
follow to reach the connector/configuration screen (replace the first
placeholder), and (2) replace the "[Additional steps to be added]" line with
step-by-step instructions for selecting the connector, configuring required
fields, saving changes, and any post-save verification actions so the guide is
complete and publishable.


After you create a rule, you'll need to save and enable it before it takes effect.

## Map attributes

For each supported attribute (like email or name), you can configure values in two ways:

**Pull from directory attributes** - Map directly from existing user attributes in your directory.

**Use CEL expressions** - Write Common Expression Language expressions with access to:
- `subject` - The ConductorOne user
- `app_user` - The app user object

CEL expressions let you map different values for different app users. For example, you could map different email formats for regular accounts versus privileged accounts.

### Add custom attributes

Some connectors support custom attributes beyond the standard schema. [Details on which connectors support this to be added]
Comment on lines +47 to +49
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Placeholder content needs completion.

The custom attributes section references connector-specific details that need to be added.

🤖 Prompt for AI Agents
In `@product/admin/push-rules.mdx` around lines 47 - 49, The "Add custom
attributes" placeholder in product/admin/push-rules.mdx must be replaced with
concrete connector-specific details: enumerate each connector (e.g.,
"Salesforce", "Zendesk", "Okta") and list the supported custom attributes and
their data types, any naming/serialization rules, examples of attribute
declarations and usage in push rules, and any limits (length, count) or required
permissions; include links or references to the connector implementation or
schema docs and a short note on how missing attributes are handled by the Push
Rules processor (e.g., ignored vs. error) so readers can implement rules
accurately.


## Filter users

You can configure filters to control which users receive attribute pushes. [Configuration details to be added]

<Warning>
Push rules rely on profile type mappings. Users must have the required attributes granted by their profile type for the rule to apply.
</Warning>
Comment on lines +51 to +57
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Filter configuration details pending; Warning component is well-placed.

Line 53 needs configuration details. The Warning component appropriately highlights the profile type mapping dependency.

🤖 Prompt for AI Agents
In `@product/admin/push-rules.mdx` around lines 51 - 57, Under the "## Filter
users" section you need to replace the placeholder with concrete filter
configuration details: describe the filter schema (attribute names, supported
operators like equals/contains/exists, value types), show at least one small
YAML/JSON example of a rule targeting users by attribute, state default behavior
when no filters are present, and add a short note linking this to profile type
mappings; keep the existing <Warning> about profile type mapping dependency in
place and reference it from the examples so readers see that attributes used in
filters must be granted by the profile type.


## How push rules work

### When attributes sync

Attribute pushes trigger automatically when:

- You enable a push rule (syncs to all applicable users)
- A user's attributes change (like a name update)
- You modify a rule's configuration (syncs to all applicable users)

Push rules don't currently detect when attributes change directly in the downstream system. Manual changes in connected systems won't be overwritten automatically.

## Use cases

### Update individual user attributes

When a single user's attribute changes (for example, a name change), the push rule automatically updates that user's attributes in the connected system.

### Bulk attribute updates

When you need to update many users at once (like changing email addresses after a company acquisition), modifying the push rule triggers updates for all applicable users.

### Manage service users

[Use case details to be added]
Comment on lines +81 to +83
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Incomplete use case section.

The "Manage service users" section needs content or should be removed if not applicable for initial release.

🤖 Prompt for AI Agents
In `@product/admin/push-rules.mdx` around lines 81 - 83, The "Manage service
users" section in product/admin/push-rules.mdx is incomplete; either populate it
with the intended use case details (describe goals, actors, steps, permissions,
and examples for service user lifecycle: create, update, revoke) under the
"Manage service users" heading or remove the heading and placeholder entirely if
this feature won't ship in the initial release; update any cross-references in
the document to reflect the change.