01/10
Illustrative office role plans
These five names illustrate responsibilities, not five automatically created roles, fixed grant bundles or security ratings. Catalog grants you select and the user’s other roles determine the outcome.
- 01/05
Partner / administrator
Office plan · verify actual grants separately
- Read needs to assess
- Resources needed for management; the role name alone opens no records.
- Operations to select separately
- User/role and report operations can be selected within authority.
- Boundary
- Does not override owner/protected-role rules or tenant/branch access.
- 02/05
Lawyer
Office plan · verify actual grants separately
- Read needs to assess
- Determine full versus assigned-case read needs separately.
- Operations to select separately
- Writes, documents, deadlines and AI require separate grants/access.
- Boundary
- Assigned-case reading alone gives no writes and does not automatically narrow other modules.
- 03/05
Trainee
Office plan · verify actual grants separately
- Read needs to assess
- Assigned-case reading is one possible plan; client/document access is separate.
- Operations to select separately
- Adding notes is not part of read-only access; it requires separate write authority and scope.
- Boundary
- The name Trainee is not an automatic identity-field mask.
- 04/05
Assistant / secretary
Office plan · verify actual grants separately
- Read needs to assess
- Assess client, appointment and calendar needs separately.
- Operations to select separately
- Creating intakes and uploading documents require separate grants.
- Boundary
- The name Assistant alone denies no case/finance access; review effective combined grants.
- 05/05
Accounting
Office plan · verify actual grants separately
- Read needs to assess
- Determine invoice/payment/report scope separately.
- Operations to select separately
- Financial operations need suitable tenant/provider configuration and grants.
- Boundary
- An Accounting role does not remove case/document grants from other roles.
02/10
How is a new role set up from start to finish?
Fictional grant plan; it executes no real role, invitation or audit operation. The example assumes no broader role/direct grants. The review-note tab is not a unified product audit screen; the menu and file count are not actual-data acceptance.
- 01/05
An authorised user assesses an illustrative Trainee role against the tenant grant catalog. The name itself grants nothing.
- 02/05
Assigned-case, client and document reads are separate grants. The first does not automatically narrow the other two resources to assigned cases.
- 03/05
An eligible account invitation is handled separately for the example person; saving a role plan sends none. This animation verifies no dispatch or delivery.
- 04/05
The assigned-case list assumes no full case read or broader grants elsewhere. Team membership alone creates no case ACL.
- 05/05
Role/session review is an office procedure. Do not assume every read, invitation and first login is written to one audit tab.
Define a role plan
03/10
Least privilege: nobody sees more than their job needs
First identify required operations and record scope. A role named Lawyer or Trainee grants nothing by its name alone; read, create, update, delete, export and management operations have separate permissions.
Role and direct grants combine for a user. Assigned-case reading does not narrow full case reading granted by another role; full reading retains its broader scope. Branch, record relationships and tenant-access conditions also apply. This guide does not treat a role assignment as proof that legal confidentiality duties were met.
Conceptual access layers, not a measured security score
- Broad operation grants
- Record/branch checks still apply
- Role plan by operation
- Choose the necessary grant for each operation
- Assigned-case reading
- Separate read scope; grants neither writes nor all-branch access
- Write down operation and record needs; choose required catalog grants.
- Review the combined effect of multiple roles and direct grants.
- Separately verify actual read/write and branch scope using a test user.
04/10
Trainees and assistants: role names are not field masks
The office determines which tasks need which data. Assigned-case reading may fit a read-only task; adding notes, uploading documents or updating records are not included in that same grant.
For a user with client-read access, a role named Trainee does not automatically hide identity/tax fields. Assigning responsibility to an intake/note creates no separate field- or note-level ACL. Assess actual role/branch/record scope and necessary data separately.
Separate task checklists, not field-level hiding on one client card
Trainee
- Assigned-case read needsExample read needs
- Separate client-read needsExample read needs
- Separate document-read needsExample read needs
- Note/write authorityAssess separately
- Identity fields and data needsAssess separately
- Other roles/direct grantsAssess separately
Assistant
- Client contact needsExample read needs
- Appointment/calendar needsExample read needs
- Intake-operation needsExample read needs
- Document upload grantAssess separately
- Finance/management grantsAssess separately
- Branch/record boundaryAssess separately
05/10
The departing-employee procedure
On departure, review company membership, branch/team relationships, assignments, sessions and external accounts separately. This guide approves no universal legal deadline or sufficient procedure for every office; the office determines a plan for its work and data.
Removing a member from a branch team removes a TeamMembers relationship; it does not close the company account or other grants. Company-user membership removal is a separate operation. It rotates the account-wide security stamp; another company membership may remain while its sessions can also require reauthentication. With no remaining membership the account may be deactivated. An existing account holder can add a company membership by signing in with the invited, confirmed email and accepting the invitation; acceptance leaves the profile, password and primary company unchanged and does not switch companies automatically. Invitation delivery depends on provider conditions.
Separate steps planned by the office, not an automatic product timeline
Membership and sessions
Distinguish company membership removal from team removal; review account sessions and remaining memberships.
Review assignments
Review case/task/appointment responsibilities using existing grants; assume no automatic bulk transfer.
Shares and keys
Review document links, API keys and external connections under their own revocation/expiry rules.
External devices and accounts
Handle corporate devices, email and other services in their respective management systems.
Review appropriate records
Case activity, account sessions and technical audit are different records; assume no exhaustive access history.
Retention and communication
Assess confidentiality, communication and retention decisions separately under office procedures.
06/10
Two-step verification (MFA)
Vekilaw supports account two-step verification, recovery codes and review/revocation of own sessions. These belong to the account, not just sessions of the selected company. Login, MFA and authority to access a company are separate checks.
Managing company MFA requirement needs appropriate authority. The actor enabling it must first have MFA enabled on their own account; the policy does not automatically enrol other members. Users complete required setup separately. This product behavior approves no specific legal or security-standard compliance.
Conceptual login and access checks
- 01Password. The user enters email and password.
- 02Second step. Complete supported second verification according to enrollment/policy.
- 03Role's authority. Evaluate effective role/direct grants, tenant/branch/record scope and access status together.
07/10
Case activity, sessions and technical audit differ
Case activity is a user-facing feed bound to permissions and case scope. Technical audit separately records supported tenant write paths; create/delete may store only the operation envelope, while updates can retain eligible changed fields with sensitive values masked. Do not assume every read or first login appears in one general audit screen.
A user’s own session list is neither technical audit nor a complete office personnel access statement. Set role/grant and assignment review intervals according to office needs. Illustrative review notes are not automatic product logs or proof of complete recording.
Fictional office review notes, not a unified product audit screen
Manager A
Reviews combined grants Role/grant list
Manager A
Reviews assignment Case record
Account holder
Reviews own sessions Account sessions
Authorised user
Reviews access needs Office procedure
08/10
The access matrix: who can do what on which resource?
The table is an office planning example. Reading or ticking a cell creates no application role and grants no permission. Compare needs against operation codes; distinguish reads from writes and resource groups from individual-record scope.
Vekilaw supports company roles and tenant permission catalogs. Role/direct grants, record/branch checks and tenant access combine. Assigned-case reading is a read-only path; it does not narrow full reading granted elsewhere.
| Resource | Partner | Lawyer | Trainee | Assistant | Accounting |
|---|---|---|---|---|---|
| Case files | Broad operation need | Separate write need | Read need | Read need | No need in this plan |
| Client records | Broad operation need | Separate write need | Read need | Separate write need | Read need |
| Documents | Broad operation need | Separate write need | Read need | Separate write need | No need in this plan |
| Invoices and payments | Broad operation need | Read need | No need in this plan | No need in this plan | Broad operation need |
| User and role settings | Broad operation need | No need in this plan | No need in this plan | No need in this plan | No need in this plan |
| AI assistant | Broad operation need | Separate write need | No need in this plan | No need in this plan | No need in this plan |
Separate write need: Cells do not define writes to assigned records. Every write separately needs a grant and suitable record/branch scope. No need in a cell does not revoke another role or direct grant held by the user.
Roles and permissions module09/10
Firm examples: one principle, three sizes
Fictional responsibility plans, not role counts to adopt, security scores or default product settings. Review other role/direct grants separately in every example.
- 01/03
A three-person firm
A small office can assess separate management, case and reception responsibilities. Role names create no access automatically.
- Managing lawyer
- 01
- Lawyer
- 01
- Assistant
- 01
- 02/03
A twelve-person firm
More responsibility plans may be useful as work is divided. Assigned-case reading gives no writes; broader record access can come from other roles.
- Partner
- 02
- Lawyer
- 05
- Trainee
- 02
- Assistant
- 02
- Accounting
- 01
- 03/03
A corporate legal department
Assess internal counsel, external counsel and reporting needs separately. Assigned-case grants do not automatically filter other resources; this example defines no multi-company provisioning method.
- General counsel
- 01
- In-house lawyer
- 04
- Outside counsel
- 03
- Reporting
- 01
10/10
Common questions about access management
- 01
Does a Trainee role hide identity fields?
The role name creates no field mask. Review client-read access and data scope separately; assigned-case reading does not automatically apply to other resources.
- 02
Can assigned-case reading add notes?
This grant alone gives no writes. Notes and other writes require separate grants and suitable record/branch scope; review full reading from other roles separately.
- 03
Does company MFA requirement automatically enrol everyone?
No. Appropriate authority is needed and the actor enabling the policy must first complete their own MFA setup. Other users complete required enrollment separately.
- 04
Does removing a team member close company access?
Removing a team relationship is not company membership removal. Manage company membership and account sessions separately; account-wide security-stamp changes may also require reauthentication for remaining memberships.
Related guide and modules
- KVKK Compliance Guide for Law Firms in TurkeyProcessing roles, the VERBIS registration exemption for lawyers and KVKK review topics for law firms. Product tools, legal assessment and operational evidence are considered separately.Read the guide (11 min)
- Legal Document Security and E-Signature GuideUploads and scanning, actual permission scope, version-pinned sharing and conditional restoration; product boundaries separate from office procedures.Read the guide (19 min)
Related modules
- Roles and permissionsSet up roles and assign permissions.
- Security and KVKKLayered protection and data isolation.