Users
Users define personal access to centraQuest. A user record is more than a login: it combines identity, status, role membership, client assignments, notification settings, workflow defaults, and sometimes module-specific approval information.
Administrators maintain login name, display name, status, e-mail address, client assignments, default settings, and module-specific fields such as notification preferences.
Important User Fields
| Field or concept | Purpose |
|---|---|
| Login name | Technical identifier used during authentication and audit logging. |
| Display name | Human-readable name shown in lists, tasks, approvals, and history. |
| E-mail address | Required for alerts, reminders, reports, and some workflow notifications. |
| Status | Only active users should receive tasks or notifications. |
| Roles | Define menu visibility, module access, administrative permissions, and client visibility. |
| Default client | Optional default mandate/accounting client for multi-client installations. |
| Entry URL | Optional personal landing page after login. |
| Notification fields | Module-specific flags such as whether the user receives alerts or reports. |
Active and Inactive Users
Inactive users should not be used as active task recipients. If a user is inactive but still appears in workflow assignments, administrators should check whether open tasks, substitutions, or old object ACLs still reference the user.
For support cases, always check the user status early. A permission problem can look like a workflow issue when the real cause is an inactive account.
User Identity in Audit Trails
Actions are recorded with the acting user. This is important for approvals and corrections: even if a user acts as substitute or administrator, the audit trail should show who actually performed the action.
Practical Checks
When a user cannot access or process a document, check:
- Is the user active?
- Does the user have the required module role?
- Does the user have the relevant client or mandate role?
- Is the user named in the object ACL, directly or through a role?
- Is the user assigned to the current workflow step?
- Is a substitution expected, and is it currently valid?
- Is the document in a lifecycle state that allows the requested action?