Configure Attribute Flow Rules
Attribute flow rules provide the most detailed level of control over attribute synchronization. These rules dictate how individual attributes are synchronized by defining the direction of synchronization, authority through weighting scores, and whether synchronization is enabled for specific attributes within each account store.
This article provides decision guidance for configuring attribute flow rules. For step-by-step procedures on configuring these rules in the EmpowerID interface, see the configuration guide for your specific connector in the Connectors (OOB) section.
For conceptual information about attribute flow architecture, see Attribute Flow.
What Attribute Flow Rules Control
Attribute flow rules are configured per attribute for each account store and define three key aspects:
Synchronization Direction — Whether attributes flow inbound (external system to EmpowerID), outbound (EmpowerID to external system), bidirectional (both directions), or are disabled (no ongoing synchronization).
Authority Through Weighting Scores — When multiple systems provide values for the same attribute, weighting scores resolve conflicts by determining which system's value takes precedence.
Synchronization Enablement — Whether synchronization is allowed or disabled for specific attributes within an account store.
Selecting Flow Direction
Use this decision framework to determine the appropriate flow direction for each attribute:
| Question | Answer | Flow Direction |
|---|---|---|
| Is there a single authoritative source? | Yes - External System | Inbound |
| Is there a single authoritative source? | Yes - EmpowerID | Outbound |
| Can multiple systems legitimately update? | Yes, latest change wins | Bidirectional |
| Should attribute sync after provisioning? | No, one-time only | Disabled |
UI Name Mapping:
When configuring in the EmpowerID interface, these directions appear with specific names in the Attribute Flow dropdown:
| Direction | UI Name |
|---|---|
| Inbound | Account Store Changes Only |
| Outbound | EmpowerID Changes Only |
| Bidirectional | Bidirectional Flow |
| Disabled | No Sync |
Flow Direction Details
Inbound (External System to EmpowerID)
Attributes flow from the external system into the Person Object. Use inbound flow when the external system is authoritative for the attribute.
When to Use:
- External system (typically HR) is the authoritative source
- EmpowerID should reflect values from the external system
- Changes in EmpowerID should not override external system values
Example: An HR system is authoritative for employee job titles. Inbound flow ensures any job title change in HR reflects in EmpowerID and subsequently in downstream systems like Active Directory.
Common Inbound Attributes:
- Employee ID
- Hire date
- Job title
- Department
- Manager
- Employment status
Outbound (EmpowerID to External System)
Attributes flow from the Person Object in EmpowerID to external systems. Use outbound flow when EmpowerID is authoritative for the attribute.
When to Use:
- EmpowerID calculates or derives the attribute value
- Policy or workflow determines the attribute value
- External system should receive but not control the attribute
Example: EmpowerID calculates email addresses based on name and location policies. Outbound flow ensures these calculated addresses propagate to Active Directory, maintaining consistent addressing.
Common Outbound Attributes:
- Email addresses (policy-calculated)
- Display names (EmpowerID-formatted)
- Account status (lifecycle-controlled)
- Group memberships (role-based)
Bidirectional (Last Change Wins)
Attributes can be updated in both EmpowerID and the external system, with the most recent change becoming authoritative.
When to Use:
- Both systems can legitimately update the attribute
- No single authoritative source exists
- Currency of information matters more than source
Example: A phone number configured with bidirectional flow allows updates from either an external system or EmpowerID, with the most recent change becoming authoritative. This accommodates users updating through self-service portals or administrators updating in directory systems.
Common Bidirectional Attributes:
- Mobile phone numbers
- Office phone numbers
- Personal information users can self-update
Important: Bidirectional rules require careful configuration. Use authority scoring to manage precedence when conflicts occur.
Disabled (No Synchronization)
Synchronization is turned off for the attribute, meaning no updates process after initial provisioning.
When to Use:
- Attribute should be set once during provisioning
- Systems should manage the attribute independently after initial setup
- Ongoing synchronization is not required
Example: If department flow is disabled for an account store, EmpowerID still writes the department value during account creation. However, subsequent department updates in EmpowerID will not synchronize to that external system.
Common Disabled Attributes:
- System-specific identifiers
- Account creation timestamps
- Initial configuration values
Initial Provisioning vs. Ongoing Synchronization:
Even when flow is disabled, initial provisioning populates attributes at account creation. The disabled setting only prevents ongoing updates from synchronizing. This enables organizations to fully populate accounts at creation while maintaining strict authority control for ongoing changes.
Authority Through Weighting Scores
When multiple systems provide values for the same attribute, EmpowerID uses weighting scores to define precedence. Each system receives three types of scores:
Create Score
Determines which system wins when an attribute is initially populated.
Use Case: During Person provisioning or account linkage, if multiple sources provide values, the source with the highest create score wins.
Example: An HR system provides an initial phone number with a create score of 50, ensuring initial onboarding data comes from the authoritative HR source.
Update Score
Determines which system wins when an existing attribute is modified.
Use Case: If multiple systems attempt to update an attribute, the source with the highest update score wins. This enables scenarios where one system provides initial values but another system is authoritative for updates.
Example: While HR provides the initial phone number (create score 50), a corporate phone system may have an update score of 55, making it authoritative for subsequent changes.
Delete Score
Determines whether a blank or missing attribute in an external system should delete the existing value in the Person Object.
Use Case: Controls whether removing an attribute value from an external system propagates as a deletion.
Example: If HR has a delete score of 80 for manager attribute and Active Directory has a delete score of 40, removing the manager from HR causes EmpowerID to remove the manager assignment. However, removing the manager from Active Directory does not remove the manager in EmpowerID, as HR is authoritative.
Scoring Configuration Examples
Example 1: Conflicting Phone Numbers
Scenario: A new employee's phone number is provided by two systems.
Configuration:
- HR System: Create score 50
- Corporate phone system: Update score 55
Result: HR provides the initial value (higher create score). When the corporate phone system submits an update, its higher update score allows the change, ensuring the most current value is stored.
Example 2: Department Attribute Synchronization
Scenario: The department attribute is managed by multiple systems.
Configuration:
- HR System: Update score 60
- Active Directory: Update score 45
Result: HR updates always apply to the Person Object. If an administrator manually changes the department in Active Directory, the lower update score prevents it from overriding the HR-provided value.
Example 3: Manager Attribute with Deletion Control
Scenario: A user's manager is stored in both HR and Active Directory.
Configuration:
- HR system: Update score 70, Delete score 80
- Active Directory: Update score 60, Delete score 40
Result: If HR removes the manager attribute, the high delete score ensures EmpowerID removes the manager assignment. If Active Directory removes the manager, the lower delete score prevents removal in EmpowerID.
Configuration Guidance by System Type
Different system types typically serve different roles in attribute authority:
HR Systems
HR systems are often authoritative for employment-related attributes:
- Job titles
- Departments
- Employment status
- Hire and termination dates
- Manager relationships
- Compensation information
Typical Configuration: Inbound flow with high create, update, and delete scores (60-80 range)
Active Directory
Active Directory may be authoritative for technical or infrastructure attributes:
- Email addresses (in some organizations)
- Office location
- Telephone numbers
- Group memberships (for non-role-based groups)
Typical Configuration: Varies by attribute—may be inbound, outbound, or bidirectional depending on organizational policies
Cloud Applications
Cloud applications like Salesforce or Workday may contribute specific attributes:
- User roles
- Profile URLs
- Application-specific identifiers
- Custom fields
Typical Configuration: Typically inbound or bidirectional, depending on whether the application is authoritative
Configuration Steps
Attribute flow rules are configured per attribute for each account store during connector setup and management.
To configure attribute flow rules:
- Navigate to your account store configuration
- Locate the Attribute Flow Rules tab or section
- For each attribute, select the flow direction from the Attribute Flow dropdown
- Enter create, update, and delete scores as needed for authority control
For detailed step-by-step procedures specific to your connector type, see the configuration guide for your connector in the Connectors (OOB) section. Each connector guide provides UI-specific instructions for configuring attribute flow rules.
Related Concepts
- Attribute Flow - Architecture and processing mechanisms
- EmpowerID Identity Warehouse - Person object and attribute storage