Lifecycle rules

Lifecycle rules describe what Qorionix should do when someone joins, changes responsibilities or leaves. For example, a rule can grant a role to a new team member, end a person's sessions or lock an account. Rules have a trigger, conditions and actions. Saving a rule configures future processing; it does not prove that an action has already happened.

Create a rule and check its effect

Open Identity automation → Lifecycle. Read the effect shown for each action before enabling the rule. You need permission to read lifecycle rules to view this page, and lifecycle write permission to create, edit or dispatch a rule. If a control is unavailable, ask your administrator to review your assigned role.

1. 1

   Choose one outcome

   Name the rule for its purpose, such as giving new finance staff a specific role. Start with a narrowly defined group of people rather than a rule that matches everyone.

2. 2

   Choose the trigger and conditions

   Select the relevant event and restrict the conditions to the people you intend to affect. Conditions are evaluated against the attributes available to that event. A field that was not supplied by the source cannot be assumed to match.

3. 3

   Review each action

   Use the human-readable effect, not an older API name, to decide what an action does. Ending sessions and locking an account are different outcomes. Check any required role or application parameters.

4. 4

   Preview before enabling

   Use the available preview or dry-run controls with a test person. A preview describes matching and intended actions; it does not make the change and does not confirm that an external application will accept it.

5. 5

   Verify a real result

   After enabling, create the intended change for your test person. Check the rule's execution result and the person's actual role, account state, sessions or application assignment. Keep the original values so you can restore the test account if necessary.

Which changes are processed automatically

The background worker evaluates lifecycle rules automatically. User creation and deactivation are checked from saved account state. Supported profile updates, attribute changes, manager changes and group membership changes are also recorded as events for the worker. Manual group changes and changes produced by dynamic group rules have event paths. Processing is asynchronous; the default worker interval is five minutes, and a deployment can configure a different interval.

A profile edit can satisfy more than one trigger. For example, changing a manager is also a user update and an attribute change. Review overlapping rules so the same person does not receive conflicting actions. The event must be recorded by a supported mutation path; do not assume a direct database edit or every external import produces the same event.

Understand the actions that are available

Grant a role gives the person the configured role in the organisation. Sign the user out everywhere revokes their active Qorionix sessions. Lock the account prevents the person from signing in until an administrator unlocks them. Locking does not remove a role, and ending sessions does not remove an application assignment. Older API definitions use names such as revoke_app and revoke_role for these latter two actions; the effect shown in the console is the behaviour to rely on.

The application-assignment execution path exists, but its availability in the lifecycle editor depends on the action capabilities published by the deployment. If it is unavailable, use the dedicated application-assignment page and verify that assignment separately. The lifecycle Run an AI tool action is not connected to a working tool executor in the standard deployment. Do not use it as evidence that an AI action ran.

If the expected change does not happen

Check that the rule is enabled, its trigger matches the change, its conditions match the supplied attributes, and its required parameters are present. Allow for background processing, then inspect the execution result and the target account. An error, missing execution or dry-run result is not successful completion. Record the person, rule and time when asking support to investigate; do not repeatedly dispatch a rule without checking what already succeeded.

Lifecycle rules and inline hooks are separate features. A lifecycle rule changes something through its configured action. An inline hook calls a registered endpoint at a supported identity event. Configuring one does not enable the other. See Inline hooks and User lifecycle and deprovisioning when designing an onboarding or offboarding process.