How policy and configuration flow down: inheritance and floors

Where a value comes from

Every configuration setting has a definition and a default. The effective value of a setting in a tenant is found in this order:

1. If the tenant has its own record, that applies (“set in this tenant”).
2. Otherwise the account's record applies (“comes from a higher scope”, source: the account's record).
3. If there is none either, the Platform's record applies (source: the Platform's record).
4. If no scope has a record, the definition's default applies (“definition default”).

Configuration screens state on every row where the value comes from. Secret values and keys whose names end like credentials are never shown under any circumstances.

What a floor is

For some settings a higher scope sets a floor. A floor is the limit below which the lower scope cannot loosen that setting. For example, if a retention period has a floor, the tenant can write a longer period but not a shorter one.

An attempt to write a weaker value is refused outright, and there is no exemption path. Whether a value is really stricter is compared at the moment of writing.

Keep in mind A floor cannot be loosened in the tenant. If a different value is really needed, the change must be made in the scope that set the floor.

Where values are written today

Configuration values are written at the platform (the platform's Configuration screen, Set a value at the Platform) and in a tenant. The account Configuration screen is read-only: even if you have config.write there, there is no path yet that writes at the account. The Policies screens are read-only too; permission rules are written by the Roles screen, and floors by configuration.