Automatic reassignment
What the features solve
There are several things in IdStory that a particular entity is responsible for: somebody guarantees a contract, somebody guarantees a role, somebody has an approval task to approve or disapprove. It is a common issue that upon the deletion or deactivation of this entity, whatever they were responsible for becomes silently orphaned which will only be found much later.
The automatic reassignment feature close this hole. When the last active holder of a responsibility is removed or deactivated, a substitute holder is resolved and assigned the responsibility, so it doesn't become orphaned.
Every implementation follows the same four steps:
- Detect - a change makes an identity stop being an active guarantor, and that identity was the last active identity responsible for the object.
- Resolve - the substitute(s) are resolved by a configurable system script, with a fallback chain that always ends with somebody.
- Assign - the substitute becomes a responsible for the object.
- Notify - the substitute receives one consolidated message listing everything they took over and why.
Examples:
- The sole guarantor of a guarded externist's contract is deactivated via an HR process - the contract is handed to the departing guarantor's manager.
- A team lead who is the sole guarantor of several application roles leaves the company and their identity is deleted - the guarantees move to their manager.
- An external consultant's contract expires; they were the only holder of a guarantee role used by ten business roles - the guarantee role is reassigned to the manager reachable through that contract.
- The only approver of a running approval task is deactivated - the task is reassigned, so the request waiting behind it can be decided.
What the features have in common
Only the last active identity matters
Nothing happens if an identity becomes invalidated while somebody else still keeps responsibility for the object. An identity that becomes inactive simply stops counting as responsible, and if another active identity remains, no substitute is resolved, nothing is assigned and no notification is sent.
The resolution chain always ends with somebody
The features resolve the substitute in a way that guarantees a result - that the guarded object is never left without an identity responsible is the business rule, so it does not depend on the configuration being complete:
- The configured system script. Only results that are identities and are active (state VALID, not disabled) are kept, and never the departing guarantor themselves. A non-empty result wins.
- The active holders of the configured fallback role. Used when the script returns nothing, returns the wrong type, fails, or is not configured at all. When the fallback role is not configured - or names a role that does not exist - the admin role (idm.sec.core.role.admin, superAdminRole by default) is used in its place.
- The admin identity. The last resort, when the role above has no active holder either.
Managers are the default answer
The scripts shipped with the features resolve the managers (superiors) of the departing identity. They therefore depend on how manager resolution is configured in the installation - the managersFor filter implementation (idm.sec.core.filter.IdmIdentity.managersFor.impl) decides this. When managers are not the right answer (i.e. we want to fall back onto a fixed support team, a role or a named list) it is possible to write a custom script.
The shipped scripts are templates
Deliberate manual changes are respected
None of the features react when an administrator removes a guarantorship by hand - an IdmContractGuarantee deleted or changed, a direct role guarantee removed, a role's guarantee role link removed. A manual removal is an explicit decision that the object should not have that guarantor, and reassigning a substitute immediately afterwards would make it impossible to carry out.
Objects on their way out are skipped
When the guarded object - or its owner - is being (force) deleted, it is flagged with the DELETED entity state and the reassignment features step aside. Transferring the guarantorship of something that is about to disappear makes no sense.
The reassignment only ever adds
One consolidated notification per new guarantor
The features which notify the substitute identity send one message per new substitute, not one per guarded object: whatever a single batch hands to the same substitute arrives as a single message listing everything at once. The message names the original responsible identity and carries a reason code saying what happened, so the recipient learns not only what they took over but why. The notification template gets the following parameters:
| Parameter | Meaning |
|---|---|
| identity | the new guarantor (the recipient) |
| originalGuarantee | the guarantor who is no longer active |
| reason | the reason code of the triggering event |
| (the guarded objects) | see the details of each particular implementation |
HR processes
Contract validity elapsing by date raises no event of its own, so the nightly HR long running tasks are what turns an expired contract into a reassignment by emitting the identity deactivation event.
Main differences between the implemented reassignment features
| Contract guarantor | Role guarantor | Approval task approver | |
|---|---|---|---|
| Available | @since 15.18.0 (not released) | @since 15.17.0 | @since 15.18.0 (not released) |
| Keeps | Identity contracts guaranteed | Roles guaranteed - direct guarantees and guarantee roles | Running approval tasks approvable |
| Switch | Off by default (idm.sec.core.contract-guarantee.enabled) and inert until the guarded projections are configured | Always on, no switch | Always on, no switch; the processor is not disableable either |
| Scope | Only identities with a configured form projection | Every role that has a guarantor | Every running approval task |
| Triggers | The guarantor identity is deleted or deactivated | Identity delete / block, contract delete / deactivation / exclusion / expiry, loss of the guarantee role assignment | The approver identity is deleted, or transitions into a disabled state |
| Timing | Asynchronous, through its own event | Synchronous, in the BEFORE phase of the triggering event | Asynchronous, as part of identity event processing |
| Transaction | Independent of the triggering transaction | Atomic with the triggering operation; a failed transfer aborts it | Independent of the triggering transaction |
| Original holder | Always removed | Kept for the reversible states (manual block, contract exclusion), removed for the destructive ones | Kept when deactivated (rendered grey, for history), removed when deleted |
| Script property | idm.sec.core.contract-guarantee.fallbackScript (not configured by default) | idm.sec.core.role.guarantee.transferScript (default roleGuaranteeTransferTargets) | idm.sec.core.wf.approval.task.reassign.script (not configured by default) |
| Script input | identity, guarantee, contract, guaranteeContracts, guaranteeManagers | identity, contract | approvalTask, lastApprover |
| Fallback role property | idm.sec.core.contract-guarantee.fallbackGuarantorRole | idm.sec.core.role.substituteFallback | idm.sec.core.role.substituteFallback (shared) |
| Shipped scripts | contractGuaranteeFallbackTargets + two demo scripts | roleGuaranteeTransferTargets (the configured default) | Three scripts, none configured by default |
| Default substitute | Managers of the departing guarantor | Managers / superiors of the departing guarantor | The fallback role holders - until a script is configured |
| Repairing history | Backfill task Assign fallback guarantor to guarded contracts, with dry run | None | None - fix by hand with the Add approvers / Remove approvers bulk actions |
| Notifies the substitute | Yes - core:contractGuaranteeFallbackAssigned | Yes - core:roleGuaranteeTransferred | No - no new task notification is re-sent |
Why the timing differs
- The role transfer has to read the live data (the guarantees, the contract, the role assignments) that the triggering change is about to destroy, and it must not leave a role unguaranteed if the change is rolled back. It therefore runs before the change, inside its transaction - at the price of a failed transfer aborting the triggering operation.
- The contract reassignment can be started by one deactivated manager with hundreds of subordinates. It therefore takes a snapshot of everything it needs, publishes its own event and runs asynchronously, so that nobody waits for it - at the price of the result only being visible once the event is processed.
Which one do I need
They are independent features guarding different objects, and an installation commonly wants both.
- Turn on contract guarantor reassignment when a category of identities - externists, contractors, service identities - must never be left without somebody responsible for them. It is off by default and needs configuring before it does anything.
- Role guarantor reassignment is on out of the box and needs no configuration to work; configure its script and fallback role when its managers-based default is not the substitute you want.
- Approval task approver reassignment is on out of the box and cannot be switched off. Configure a script when the fallback role is too blunt an answer - the shipped managers of the last approver script is the usual choice.