Permissions, departments and Administrator EX

Understand the three checks before changing access

A person's tier establishes ordinary capabilities. Page rules then determine which actions are available on a particular page. Record ownership adds another check when a person changes equipment maintained by another department. Treat these as separate questions: can the person open the page, can they perform this action, and may they change this record? A visible row or an enabled navigation link alone answers none of the later questions.

Use the person's actual identity and assigned department when reviewing access. A directory account takes the highest-ranked tier group it belongs to. Without one, its stored assignment applies, then the administrator group, then the default tier. Removed access is different from a low tier: the record remains to identify the person in history, while sign-in is refused. Do not create another identity to work around a restriction.

Choose the appropriate tier

Choose a tier for the responsibility the person has, then narrow page access as needed. Do not promote someone to Administrator EX merely to make one button work. A department administrator may open the audit-log page but does not receive district-wide audit rows through that capability alone. Auditor and Administrator EX have the separate district audit capability.

Administrator EX is a deliberate exception to page-rule denials. A Block assigned to its department or its named account will not remove its page actions. Testing restrictive rules while signed in as Administrator EX therefore cannot demonstrate how an ordinary account behaves.

Scroll the table sideways to read all columns.

Review department and person rules

In Page permissions, choose whether the rule applies to A department or A specific person. Select the department, then the person when appropriate. Department administrators are limited to subjects they may manage within their department; Administrator EX can work across departments. Confirm the selected subject before editing a whole row or column.

Each action can be Inherit, Allow or Block. Inherit follows the tier and then the applicable department rule. A named-person decision overrides the department decision for that action, but ordinary View, Download, Create, Edit and Delete permissions remain bounded by the person's tier. Blocking View also disables the other page actions, so a separate Edit allowance cannot reopen a hidden page.

The underlying access policy also supports named-person Design delegation for a specific page, without granting ordinary editing or general structural administration. The ordinary Page permissions grid does not display a Design column. If an existing design delegation affects the case, ask an administrator to review that delegation separately rather than assuming the visible five-action grid describes every capability.

Save a controlled permission change

1. Identify the page and action the person needs. Review the tier, department and any personal rule before editing.
2. Change the smallest appropriate set of cells. Use whole-row or whole-column controls only after checking the selected person or department and the pages affected.
3. Review the changed-page count and choose Save. Unsaved drafts are not active permissions.
4. If saving stops partway through several page rules, review what is already stored. The page saves rules individually; earlier successful rules can remain saved even if a later rule fails.
5. Reload after a version conflict and compare the newer rule before trying again. If the outcome is reported unknown, read the saved rules first rather than repeating a possibly committed change.
6. Verify both the intended allowed action and an action that should remain refused using the affected account. Reload the page or sign in again where required to obtain current access.

Reset rules without mistaking inheritance for permission

Discard changes removes the current unsaved edits. Reset every page to inherited removes stored rules for the selected subject after confirmation; it does not assign a new tier or grant all actions. The resulting access still comes from the tier, department policy, page requirements and record checks. A personal reset can therefore reveal a department Block that a personal Allow previously overrode.

When an API refuses a request, do not assume the screen is merely hiding a feature incorrectly. Direct requests are checked too. A missing or unavailable permission store can refuse access rather than guess. Keep the original error, subject and page details when asking an administrator to investigate.

Distinguish department visibility from ownership

An asset's owning department identifies who maintains it. For ordinary accounts, a foreign owner can make an otherwise visible asset read-only. The server also checks attempts to assign a different owning department, preventing a person from bypassing the boundary by changing the owner while editing. Administrator EX has cross-department authority; an ordinary administrator does not acquire it merely through structural permissions.

Page visibility and department ownership are not a promise that every record in every feature is globally visible. Some pages and reports apply their own permitted scope. When troubleshooting, compare the actual page, account department and record owner. An asset with no recorded owner is also distinct from one explicitly assigned to another department; establish the correct owner through the approved record workflow.

Maintain departments and directory mappings

Only Administrator EX can change the shared department configuration or review department removal impact. A department may supply its label, directory mapping and navigation configuration. Saved directory mappings override the corresponding defaults, and removed mappings are represented explicitly. Review existing assignments when changing a mapping; changing navigation is not the same action as transferring ownership of equipment.

Before removing a department, review its usage. References include people, page rules, assets, closets, designs, custom pages and notices. Cenovel refuses removal while references remain. Reassign or resolve those records deliberately, then request the impact review again. Do not try to remove a department by repeatedly submitting the same rejected form.

Resetting departments has a preview of what would change. It also checks whether a removed department is still referenced. The reset preserves category claims, branch lists and colours where shipped defaults do not define replacements. Read the preview rather than assuming Reset empties every department setting.

Preserve accountability and verify the outcome

Permission-rule changes are versioned and recorded with their audit information. Department saves and resets record security audit entries describing the change. People whose access is removed remain identifiable in historical records. Use these records to explain who changed access and what was stored; an audit entry is not proof that every downstream account has already refreshed its session.

For a refused request, collect the page, action, person, department, record owner and exact message. For a successful change, revisit the effective permissions and perform one representative workflow. Verify department boundaries with an ordinary account and Administrator EX behavior separately. This keeps an intentional privilege exception from concealing an error in the policy intended for everyone else.