Policy Rules
Identity Mesh uses four rule types to control how identity data is correlated, imported, enriched, and exported across your connected systems.
The Four Rule Types
Each rule type handles a distinct phase of the identity synchronization pipeline. Together they define how objects are matched, how attributes flow in, how the mesh is enriched, and what gets exported.
Join Rules
Anchor-based identity correlation. Match imported management-space objects to existing mesh objects using attribute comparison.
Flow Rules (Inbound)
Map attributes from management space into mesh objects. Each rule carries a confidence score and an optional transform script.
Projection Rules (Outbound)
Control which mesh objects are exported to target connectors. Filter by attributes, specify the object type and target container.
MeshComposer Rules
Enrich mesh objects with computed values using transform scripts. Generate derived attributes like usernames or display names during composition.
Join Rules
Join rules define how imported objects from a connector are correlated to existing mesh objects. When a connector imports an object, the engine reads the SourceAttribute value directly from the raw connector data and searches existing mesh object attributes for a matching TargetAttribute value. Join rules are independent of inbound flow rules — the join uses raw connector attributes, not flowed attributes. Multiple join rules per connector are evaluated in priority order until a match is found. If no match is found and an anchor rule permits creation, a new mesh object is projected.
Fields
How Join Matching Works
1. The engine reads the SourceAttribute value directly from the raw connector object (case-insensitive lookup).
2. It searches IM_MeshObjectAttributes for any mesh object that has TargetAttribute = value.
3. As a fallback, it checks IM_MeshObjects.AnchorValue for a match.
4. If multiple join rules exist, they are evaluated in order until the first match is found.
5. If no match is found and an anchor rule exists, a new mesh object is projected with the anchor value set.
Example
Join Rule 1: "Match AD Users by Employee ID"
Connector: Corporate AD
SourceAttribute: employeeID (raw AD attribute)
TargetAttribute: EmployeeId (mesh attribute to search)
IsAnchor: true
Join Rule 2: "Match AD Users by sAMAccountName"
Connector: Corporate AD
SourceAttribute: sAMAccountName (raw AD attribute)
TargetAttribute: sAMAccountName (mesh attribute to search)
IsAnchor: false
// The engine reads employeeID directly from the AD object,
// then searches mesh object attributes for EmployeeId = "12345".
// Join rules work independently of inbound flow rules —
// no flow rule is needed for the join to match.
// Multiple rules are evaluated in order until a match is found.Flow Rules (Inbound)
Flow rules map attributes from management-space objects into mesh objects during inbound synchronization. Each rule specifies which source attribute feeds which target attribute, along with a confidence score and an optional transform script.
Fields
Example
Flow Rule: "Import AD Display Name"
Connector: Corporate AD
Direction: Inbound
SourceAttribute: displayName
TargetAttribute: DisplayName
Confidence: 80
TransformScript: Concat(Left(givenName, 1), ". ", sn)
// Transforms "John Smith" into "J. Smith"
// Confidence 80 means this value wins over any
// source contributing the same attribute at lower confidence.Projection Rules (Outbound)
Projection rules control which mesh objects are exported to target connectors. They define the object type, an optional filter expression, and the target container (such as an OU or database table) where objects are provisioned.
Fields
Example
Projection Rule: "Provision to HR Database"
TargetConnector: HR Database
ObjectType: User
Filter: department != "Contractors"
Container: dbo.Employees
// Only non-contractor users are projected
// to the HR Database connector's export queue.
// Container specifies the target table or OU.MeshComposer Rules
MeshComposer rules enrich mesh objects with computed values during composition. They run after inbound flow rules and allow you to derive new attributes from existing ones using transform scripts.
Fields
Example
MeshComposer Rule: "Generate SamAccountName"
TargetAttribute: SamAccountName
TransformScript: ToLower(Concat(Left(FirstName, 1), LastName))
Confidence: 90
// Composes "jsmith" from FirstName="John", LastName="Smith"
// Runs during mesh object composition, enriching
// the mesh with computed values before export.Built-in Functions
TransformScript expressions use a whitelisted set of built-in functions. No arbitrary code execution is allowed -- only these safe, deterministic functions are available.
String Functions
- ToLower - Convert to lowercase
- ToUpper - Convert to uppercase
- Trim - Remove leading/trailing whitespace
- Replace - Replace substring
- Concat - Concatenate strings
- Left - Extract N characters from start
- Right - Extract N characters from end
- Substring - Extract substring by position
- Split - Split string by delimiter
- Join - Join array with delimiter
Date & Utility Functions
- Now - Current timestamp
- Format - Format value to string
- Coalesce - First non-null value
Logical Functions
- If - Conditional value
- Switch - Multi-branch selection
Conflict Resolution
When multiple connectors contribute values for the same attribute on a mesh object, Identity Mesh resolves the conflict using confidence-based scoring.
Confidence Score per Rule
Each flow rule and MeshComposer rule assigns a confidence score (0-100) to the attribute value it produces. This score represents how authoritative that source is for the given attribute.
Highest Confidence Wins
When multiple sources contribute a value for the same attribute, the value with the highest confidence score is written to the mesh object. This is evaluated per attribute, not per object.
Practical Example
If Active Directory provides DisplayName at confidence 80 and Workday provides it at confidence 95, the Workday value wins. If a MeshComposer rule generates it at confidence 60, it only takes effect when no higher-confidence source is available.
Per-Object Attribute Override Coming Soon
Override the confidence score for a specific attribute on an individual mesh object. This allows administrators to pin a particular value for edge cases without changing the global rule, giving fine-grained control when the default resolution doesn't fit a specific identity.
Best Practices
Start with join rules
Establish reliable identity correlation before defining flow or projection rules. Poor join logic leads to duplicate mesh objects and mismatched attributes.
Test with small datasets
Always test new rules with a small subset of data before enabling them for production.
Be intentional with confidence scores
Assign confidence scores that reflect the actual authority of each source. Your HR system should typically have the highest confidence for employee attributes, while computed values from MeshComposer rules should have lower scores as fallbacks.
Use descriptive rule names
Give your rules clear, descriptive names that explain their purpose. This helps future maintainers understand the synchronization logic at a glance.
Use projection filters to limit scope
Apply filters on projection rules to avoid exporting unnecessary objects. Only project what the target system actually needs.
Monitor sync results
Regularly review the audit log to catch join mismatches, transform errors, and unexpected attribute values early.