Workflow configurability matters because it lets teams adapt governance processes without building and maintaining resource intensive code. That reduces implementation overhead, makes change faster, and lowers the chance that identity controls become brittle as business needs shift. In practice, configurability supports repeatable governance while custom code often creates long term maintenance and upgrade friction.
Why configurability changes the economics of IGA
Workflow configurability matters because IGA is rarely static. Joiner, mover, leaver processes, access certifications, approvals, and exception handling all change as organisations add systems, merge teams, or tighten policy. A configurable platform lets you adjust those governance flows without rewriting logic each time, which keeps the identity control plane IAM and IGA Basics aligned to the business instead of forcing the business to fit the code.
That is why configurability usually scales better than custom code. Configured workflows are easier to inspect, document, test, and hand over, while custom code tends to hide process logic inside scripts, plugins, or point fixes. When the business changes, the team can update a rule, route, or approval path instead of funding a small software product every time policy shifts.
Configurability also preserves governance intent. In identity programs, the objective is not just to make approvals happen, but to make them repeatable, reviewable, and consistent across populations and systems. A configurable workflow can express different treatment for high-risk access, recertification, and exception routing while still using the same governance model. That matters because identity controls lose value quickly when each exception becomes a one-off development effort rather than a managed policy decision.
Where custom code usually becomes the bottleneck
Custom code in IGA is rarely expensive only at build time. It creates an ongoing dependency on developers, release cycles, regression testing, and platform-specific upgrades. A workflow that started as a practical shortcut can become brittle once it is coupled to old role logic, hidden approval branches, or an integration that only one engineer understands. The more bespoke the code, the more likely the next change becomes a project rather than an administration task.
That brittleness shows up in several common ways. First, change velocity drops because even simple policy edits require code review and deployment. Second, upgrade friction rises because custom logic can break when the vendor platform changes. Third, operational risk increases because teams hesitate to touch a fragile path, which is how outdated approvals, stale entitlements, and workarounds persist longer than they should. The result is often governance drift, not just technical debt.
Custom code can still be justified where a process is genuinely unique or tightly integrated with a critical control, but it should be treated as the exception, not the default design pattern. A configurable platform keeps the organisation closer to the standard product model, which usually improves supportability, auditability, and the chance that access governance keeps working after the next organisational change.
How to decide whether a workflow belongs in configuration or code
The practical test is whether the workflow expresses policy or implements a special capability. If it is mainly routing, approvals, thresholds, notifications, segmentation of duties checks, or lifecycle handling, configuration should usually be the first choice. If it depends on a truly unique calculation, an external system constraint, or a non-standard control requirement that the platform cannot express safely, then code may be appropriate.
For identity governance teams, that decision is also about ownership. If business admins and control owners can safely maintain the workflow, configuration is usually the better answer. If the logic requires frequent engineering intervention, the organisation should ask whether the process is too bespoke, too fragmented, or too coupled to fragile downstream systems. A good IGA design reduces the number of places where policy can only be changed by a developer.
That is the long-term advantage of configurability: it supports policy evolution without turning every governance change into a software change. In modern iga, that difference is often what separates a sustainable control from one that slowly becomes obsolete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | IGA workflows manage account lifecycle and access changes. |
| AC-6 — Least Privilege | Workflow design should limit access changes to what policy requires. | |
| Recommendation — Use AC-2 to keep identity workflow changes governed, reviewed, and aligned to account lifecycle rules. Apply AC-6 to ensure workflow-driven access decisions grant only the minimum required privilege. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IGA workflow configurability supports enforceable access control governance. |
| Recommendation — Use A.5.15 to keep access workflow changes policy-based and auditable. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | IGA workflows operationalise access requests, approvals, and reviews. |
| Recommendation — Use CIS-6 to standardise access approvals and reviews through configurable workflows. | ||
| OWASP ASVS | V8 — Authorization | IGA workflows implement authorization decisions through approvals and entitlement rules. |
| Recommendation — Use V8 to keep authorization logic explicit and maintainable rather than hard-coded. | ||
Practitioner Guidance
What to prioritise: Standardise the highest-volume identity workflows first, especially joiner-mover-leaver, access requests, and certifications, because those are the areas where custom code creates the most maintenance drag and the most process fragility.
What to verify: Confirm that the platform can express the business rule with native workflow, policy, and connector features before approving custom development. If the requirement only exists because of an old process habit, treat that as a redesign candidate rather than a coding requirement.
Common mistake: Teams often use custom code to handle edge cases that should really be handled as configurable exceptions. That makes the exception path the permanent design, which is usually where upgrade pain and control drift begin.
Practitioner takeaway: In IGA, configurability is valuable not because it is simpler at the moment of change, but because it keeps governance adaptable, supportable, and auditable as access rules evolve.
