TL;DR

• Approval does not prove access was successfully granted, changed, or removed.
• Access fulfillment automation should convert an approved governance decision into a controlled target-system action.
• Different applications may use direct provisioning, APIs, SCIM, ITSM workflows, or administrator-led fulfillment.
• Reconciliation compares the expected access state with the actual state reported by the target application.
• Failed, partial, and delayed changes need visible ownership rather than disappearing inside provisioning logs.
• Audit evidence should connect the original request or decision with fulfillment status and final verified access state.

The Access Request Says “Completed.” The Employee Still Cannot Log In.

A new finance analyst requests access to an accounting application.
The manager approves it at 10:04 a.m.
The application owner approves it at 10:17.
By 10:18, the access request portal says:
Completed.
At 2:00 p.m., the analyst still cannot access the application.
IT investigates.
The account exists, but the required finance entitlement was never assigned. An integration returned a partial error that nobody noticed.
Now reverse the scenario.
A terminated contractor’s removal request also says “completed,” but one privileged entitlement remains active.
Both workflows looked successful from the governance platform.
Neither produced the expected access state.
This is why access fulfillment automation should not stop at sending a provisioning command or closing a ticket.
Organizations also need reconciliation: proof that the application actually reflects the approved decision.

What Is Access Fulfillment Automation?

Access fulfillment automation is the process of converting an approved identity governance decision into an access change in the target environment.
That change might:

• create an account
• enable an account
• add an entitlement
• assign a role
• remove an entitlement
• disable an account
• update existing access

A practical workflow is:
Request or trigger → Decision → Approval → Fulfillment → Reconciliation → Verified state → Evidence
SecurEnds’ current Application Access Request capabilities connect access requests and approvals with provisioning workflows, while its broader IGA content describes provisioning and deprovisioning as part of the governed identity lifecycle.
The distinction between approval and fulfillment is important.
Approval says the change is authorized.
Fulfillment attempts to make the change.
Reconciliation establishes whether the expected change actually happened.

Why Is Approval Status Not Enough?

An access governance platform may correctly approve a request while fulfillment still fails.
Common reasons include:

• connector failure
• API timeout
• incorrect target identifier
• missing account
• unsupported entitlement
• application outage
• administrator error
• ticket left unresolved
• target-side policy conflict
• partial provisioning

Consider a request containing three permissions.
Two succeed.
One fails.
If the request is marked simply “completed,” the requester and governance team may believe the intended access exists.
The same issue is more serious with revocation.
If a removal action fails but appears complete, unwanted access remains active.
That creates a control gap between the governance decision and the application state.

What Should a Closed-Loop Fulfillment Workflow Look Like?

1. Start With a Clear Expected Access State

Before fulfillment begins, define exactly what should change.
For example:
User: Priya Shah
Application: Finance ERP
Expected change: Add Invoice_View and AP_Analyst
Approval: Completed
Duration: Permanent until lifecycle or review change
This gives the fulfillment process something measurable.
A vague instruction such as:
“Give Priya finance access”
is difficult to reconcile later.
The same rule applies to revocation.
Define the exact account, role, group, or entitlement that should disappear.

2. Choose the Right Fulfillment Path

Not every application needs the same execution model.

Direct automated provisioning

For supported systems, the governance platform can send the approved access change directly to the target.
Common mechanisms may include standardized APIs such as SCIM or other supported application interfaces.
SecurEnds’ T-Hub capability currently documents provisioning, updates, and access revocation through SCIM and REST-based integration patterns, including use with directories, identity providers, and custom applications.

ITSM-driven fulfillment

Some applications are still administered through internal IT teams.
The governance decision may create controlled work in an ITSM platform for the appropriate administrator.

Manual fulfillment

Legacy or highly specialized applications may require an application administrator to make the change manually.
Manual does not need to mean uncontrolled.
The important requirement is keeping:
decision → owner → action → status → verification
connected.

Fulfillment Status Should Be More Specific Than “Done”

Use statuses that reflect what actually happened.
For example:

Status	Meaning
Approved	Governance decision is complete
Pending fulfillment	Change has not yet been executed
In progress	Execution has started
Partially fulfilled	Only some requested changes succeeded
Failed	Target change did not complete
Fulfilled	Execution reports completion
Reconciliation pending	Target state has not yet been checked
Verified	Target state matches expected access

The terminology can differ.
The critical point is that fulfilled and verified are not necessarily the same state.
That distinction helps prevent false closure.

What Is Access Reconciliation?

Access reconciliation compares the access the governance system expects with the access the target application actually reports.
Suppose an approved request should add these two entitlements:

CRM_User

Sales_Reporting

After fulfillment, the governance platform retrieves fresh information from the target.

Expected state

Both entitlements present.

Actual state

CRM_User present.
Sales_Reporting missing.
The correct outcome is not “complete.”
It is a reconciliation exception requiring investigation.
The same process applies to removal.
If an entitlement should have disappeared but still appears in refreshed source data, the revocation has not reached verified closure.
SecurEnds’ existing IGA content describes closed-loop provisioning in which governance decisions can result in deprovisioning against connected identity platforms rather than stopping at the review decision itself.
Its Epic identity-governance offering also explicitly describes fulfillment followed by reconciliation and preservation of implementation confirmation, illustrating the same closed-loop operating principle.

Why Should You Reconcile Automated Changes?

Automation reduces manual effort.
It does not eliminate failure.
A provisioning connector can fail.
An API can accept a transaction but not apply every requested change.
A downstream process can overwrite the result.
An account can exist under a different identifier.
A later application update can restore access unexpectedly.
Reconciliation gives the governance platform a way to ask:
Does today’s actual access match the access we intended to create?
That question is essential for both provisioning and deprovisioning.
Without reconciliation, you know what the platform attempted.
You may not know what the target ultimately contains.

What Should Happen When Reconciliation Fails?

A mismatch should create an actionable exception.
Do not leave it buried in a technical integration log.
A useful exception should identify:

• identity
• target application
• expected access
• actual access
• failed or missing entitlement
• original request or governance event
• fulfillment method
• failure timestamp
• accountable owner
• retry or remediation status

Then determine the next action.

Retry

Appropriate when the problem was transient.

Route to administrator

Useful when automation cannot complete the change.

Correct identity or entitlement data

Required when matching or target metadata caused the failure.

Escalate

Appropriate when a high-risk removal remains unresolved.

Record an exception

Use only when the organization intentionally accepts the resulting state under an approved process.
Do not automatically convert a technical failure into business approval.

Provisioning and Deprovisioning Need the Same Verification Standard

Organizations often focus heavily on successful onboarding.
Deprovisioning deserves at least the same control.
A failed provisioning action usually creates a productivity issue.
A failed deprovisioning action can leave inappropriate access active.
For example:
Termination event received
Expected:

• directory account disabled
• CRM access removed
• finance account disabled
• administrator entitlement removed

Actual:

• directory account disabled
• CRM access removed
• finance account still active
• administrator entitlement still active

If the process records only that the termination workflow ran, security teams can miss the remaining exposure.
SecurEnds’ current provisioning content emphasizes provisioning, deprovisioning, and role changes as connected lifecycle processes rather than isolated transactions.

How Does Fulfillment Work for Legacy Applications?

Not every target application supports direct write-back.
A legacy workflow may look like:
Approved request → application-owner task → manual access change → updated application extract → reconciliation
This can still be governed.
The difference is execution method.
For example:

1. Access request is approved.
2. A task goes to the application administrator.
3. Administrator grants the entitlement.
4. Application data is exported again.
5. New data enters the governance platform.
6. Expected and actual access are compared.
7. Request moves to verified closure.

This is stronger than assuming a completed service ticket proves the target changed.
The same model can support difficult homegrown, database, or file-fed applications.

Which Metrics Should You Track?

Fulfillment automation should produce operational metrics.

Fulfillment success rate

Successful fulfillment actions ÷ Total fulfillment actions

Reconciliation success rate

How many completed actions match the expected target state?

Partial fulfillment rate

How frequently does only part of a requested access package succeed?

Average fulfillment time

How long does it take to move from approval to target-system execution?

Average verification time

How long from approval until the target state is confirmed?

Failed revocation count

How many removal actions remain unresolved?

Manual fulfillment percentage

How much of your access estate still requires administrator intervention?
These metrics show where your governance program remains dependent on manual work or unreliable integration.

What Should Buyers Look for in Access Fulfillment Automation?

During software evaluation, ask the vendor to demonstrate:

• direct provisioning methods
• entitlement-level provisioning
• deprovisioning
• ITSM-based fulfillment
• manual fulfillment tracking
• status visibility
• partial failure handling
• retry behavior
• reconciliation
• expected-versus-actual access comparison
• exception ownership
• audit history

Do not stop the POC after an approver clicks Approve.
Ask the vendor to prove that the target application changed.
Then deliberately create a failure.
You need to understand what operators see when automation does not work.

How SecurEnds Supports Fulfillment Across Different Application Types

SecurEnds currently positions access requests as a process that connects request, approval, provisioning, and deprovisioning across governed applications.
For systems that support direct integration, SecurEnds’ T-Hub provides SCIM- and REST-based connectivity for provisioning, updating, and revoking access across supported targets and custom applications.
SecurEnds also documents real-time visibility into access-request progress, including approval and fulfillment stages, helping requesters and administrators distinguish a submitted request from one that has progressed through execution.
For buyers, test the workflow using more than one application type:
Application 1: Direct automated provisioning
Application 2: Controlled administrator fulfillment
Application 3: Difficult or legacy application
Then compare how each reaches a provable final state.

Best Practices for Access Fulfillment and Reconciliation

Define the expected state precisely. Know exactly what should be granted or removed.
Separate approval from execution. An approved request has not necessarily reached the target.
Separate fulfillment from verification. Execution success is stronger when confirmed through refreshed application data.
Track partial failures. Multi-entitlement requests should not appear successful when only some changes occurred.
Make failures visible. Give unresolved changes to owners and escalation paths.
Prioritize revocation failures. Unremoved access may represent greater risk than delayed provisioning.
Support different execution methods. Automate appropriate systems while keeping manual targets controlled.
Document everything. Preserve the decision, fulfillment method, target response, exception, reconciliation result, and final closure.

Frequently Asked Questions

What is access fulfillment automation?

Access fulfillment automation turns an approved access decision into a change in the target application or identity system. It can create accounts, assign roles or entitlements, update access, or revoke permissions. Mature workflows also track failures and confirm that the target state reflects the approved decision.

What is the difference between access approval and fulfillment?

Approval authorizes the access change. Fulfillment executes it. A manager may approve an entitlement, but an integration or administrator must still grant it in the target application. Keeping the two states separate prevents an approved request from being mistaken for successfully provisioned access.

What is access reconciliation in identity governance?

Access reconciliation compares the access the governance system expects with the actual account and entitlement data retrieved from the target system. It helps identify missing provisioning, failed removals, unexpected permissions, and other differences between intended and real access.

Why is reconciliation important after automated provisioning?

Automation can still fail or produce partial outcomes. Reconciliation provides independent confirmation that the target application’s current state matches the authorized change. This is particularly important when proving revocations and other security-sensitive changes were actually completed.

How do you fulfill access for legacy applications without provisioning connectors?

Use a controlled manual or ITSM-based workflow. Assign the approved change to the responsible administrator, record completion, obtain refreshed application data, and reconcile the resulting state. This preserves accountability even when direct write-back automation is unavailable.

What audit evidence should fulfillment retain?

Retain the original request or trigger, approved access, approvers, target application, fulfillment method, execution status, errors, responsible owner, reconciliation result, and timestamps. The record should make it possible to demonstrate that an authorized access decision resulted in the expected target-system state.

Do Not Measure Success at the Approval Button

Approval is an important governance event.
It is not the final outcome.
The employee needs the approved access to exist.
The terminated user needs the revoked access to disappear.
The application needs to reflect the intended state.
And your security or audit team needs evidence that the change occurred.
That requires a closed loop:
Decide → Approve → Fulfill → Reconcile → Verify → Document
If your organization still treats a completed approval or closed ticket as proof that access changed, evaluate SecurEnds Application Access Request and IGA provisioning capabilities against a real target application and follow the transaction through to its final access state.