Declarative, not code
Logic is expressed as configuration, so it can be reviewed, changed and reasoned about without a development cycle.
Shape identity data without writing a connector
A declarative engine for lookups, decisions and pipelines — configuration rather than code.
Identity data never arrives in the shape you need it. Job codes have to become roles, names have to be normalised, values from two sources have to be reconciled. The expressions and transforms engine does that declaratively, so the logic lives in configuration that can be read and reviewed instead of in bespoke connector code only its author understands.
How Expressions & Transforms works
The mechanics behind the capability — what the platform does, and where it does it.
Pipelines
Chain transforms so a value passes through several steps, which keeps each step simple and testable.
Lookups and mappings
Translate source codes into the values your policies use, without hard-coding the table into a connector.
Reusable where it is needed
The same expression applies across attribute mapping, provisioning and policy, instead of being reimplemented per integration.
What it changes
Who feels the difference once Expressions & Transforms is in place, and how.
Identity teams
Changes take hours, not sprints
Adjusting a mapping is a configuration change rather than a release of custom connector code.
Platform owners
Logic survives its author
Declarative rules remain readable when the person who wrote them has moved on.
IT operations
Fewer bespoke integrations
Much of what would justify a custom connector turns out to be a transform.
Audit
Reviewable decisions
When policy logic can be read, it can be checked — which is hard to do with compiled code.
See Expressions & Transforms in context
It works because the other capabilities share the same identity fabric. The quickest way to judge that is to watch it run against your own use cases.