Skip to content

When a Change Takes Effect

Applies to: All subscriptions

Purpose

A change to a control is enforced by the server within a minute, but a screen that is already open keeps showing the old state until its user signs in again. Both are true, and they are the reason a changed setting can look "not applied" to one person and "already applied" to another. A change to a person's access works the other way round: it signs them out when it is saved, so they cannot keep using the old access at all.

The table below is generated from the product, the same source the Why can't they? view reads, so it cannot disagree with it.

Audience

Administrators and consultants who change roles, registrations and controls, and support staff answering "I changed it and nothing happened".

Prerequisites

Reference

What reaches whom, and when

You change The server applies it The person affected
A person's role, approval role or registrations (or deactivating or deleting them) At once: their sessions end when the change is saved, in the same step. They sign in again and get the new access then. Until they do they cannot use the old one.
End sessions on a person At once. They can sign in again straight away: it does not change their account.
An operational control: a module switch, segregation of duties, an approval or credit rule (company default, registration override, or removing one) On the next request, and within 60 seconds at the latest. Values are cached for 60 seconds and a save clears the cache. Screens that are already open keep showing the old state (which tiles and buttons appear) until the person signs in again, because screens receive control values at sign-in. The server enforces the new value regardless.
What a role is allowed to do (the permission table itself) When a new version of the product is deployed. Nobody can change it from a screen. People signed in at the time of the deployment get it on their next sign-in.
  • Changing a person's role, approval role or registrations ends their sessions when the change is saved; the new access applies when they sign in again.
  • End sessions signs the person out of every device at once, and they can sign in again straight away.
  • A change to a control is enforced on the next request, and within 60 seconds at the latest. Screens that are already open keep showing the old state until the person signs in again.
  • What a role may do changes only when a new version of the product is deployed, and applies to a person at their next sign-in.

What to tell the person who is waiting

They say What is happening What to do
"I switched the module on and my button is still missing" The server already accepts it; their screen received the old value when they signed in Ask them to sign out and in again
"I changed their role and they still have the old menu" They cannot: saving the change ended their sessions. If they appear to, they signed in again before the change was saved, or a second device was signed in as them Check the audit log for SESSIONS_REVOKED for that person
"I relaxed segregation of duties and a maker still cannot generate an IRN" The server applies it within a minute. Their screen shows the buttons from their last sign-in Wait a minute, then ask them to sign in again
"I switched a control off and a document still went through" A request already in flight, or one inside the same minute on another node whose cache was not yet cleared Check the time of the change in the control's Audit History against the document
"I need a role to be able to do something it cannot" A role's permissions are not a setting. They change only with a new version of the product Use the role that holds the permission, or ask Complifly

Validation

Check Method Pass condition
A control change reaches the server Change a control, then make the request it governs Refused or allowed accordingly within a minute
A control change reaches the screen Ask the person to sign in again The buttons and tiles match
An access change ends sessions Change a role, then use the old session The old session is refused with "Your role was changed"

Troubleshooting

Symptom Cause Action
A change appears not to apply for several minutes Shared cache unavailable, so each server holds its own for up to 60 seconds Wait one minute. If it persists, the change was not saved: check Audit History
Two people see different buttons for the same registration One signed in before the change and one after Both sign in again