Let's start with the team's duties.
Arrange roles according to the job, such as reception, service provider, cashier, manager, and system administrator. Then set permissions to view, create, edit, or make specific transactions as supported by the system. The actual menu visibility and transaction permissions must match the role and scope of information.
Roles and branches must be checked together.
Multi-branch users may have different scopes than regular branch users. Service data, documents, finance, and reports have relevant rights. Therefore, each role should be tested to ensure that it can see and complete assigned tasks.
Permissions, approvals, and history are related tasks.
| Topics | Duty |
|---|---|
| Rights | Determine who has access or what kind of transactions. |
| Approval | Allow the authority to consider job-specific requests, such as price exceptions. or cancellation of supported courses |
| Transaction history | Check the author, time, reason, and changes stored by the system for that job. |
The owner has a defined usage history view, and Documents, Receipts, and Approval Requests have a history of related transactions. Signing documents is another duty. Therefore, document policies must be checked along with rights.
Accessibility to the extent provided.
in supported rescue tasks The owner manages access for a period of time. Withdraw when you no longer want to use it. and check the history of related assistance So that the problem solving has a scope that can be verified.
How to use it every day?
Specify the function:
Separate tasks that each role must see and do.
Assign permissions to branches:
Grant relevant permissions and designate reviewers for tasks that require approval.
Test and review:
Use each role's account to check the actual work. Then review rights when duties or teams change.
Frequently asked questions
Is hiding the menu only equal to setting all permissions?
Transaction rights and data scope must also be specified. The menu is only part of the experience. Administrators should test real-world work with each role account.
Is the approver the same as the person signing the document?
It's a different role. Request for approval to use authority for that work The signature section applies the rights and policies of the document. Inserting a signature does not record that the action request has been approved.
Does the system keep a history of every opening, reading or every action?
This page describes usage history and supported items such as requests, documents, or finances. The scope of each history is different. Therefore, it should not be assumed that every opening, reading and every action has the same detailed audit.
Can the support team gain access and then stop access?
Supported help tasks have periodic and revocable entitlements. Ready to check relevant history The owner should set boundaries based on the problem that needs help.