Lawcus’s help-center example shows New Role with selectable feature permissions over the organization’s Roles & Permissions page. Use it to map duties and test a narrow role; this unsaved example does not prove a user’s effective access or matter visibility.[1] View full-size image
Use this Lawcus access review when a new user needs a narrow role, a sensitive matter needs restricted membership, or a departure requires access to end without losing attribution. Check the organization role, matter participation, portal sharing and connected services separately. For an urgent authorized cutoff, end access at the approved time; unfinished record handoffs belong to the remaining authorized team and must not keep the departing account open.
Lawcus documents four default roles: Admin, Member, Client, and Co-counsel. It also supports custom roles with feature permissions, and custom roles can be restricted by IP address. The default Admin and Member roles include core permissions that cannot all be unticked, so a firm should not force every employee into those defaults when a narrower custom role better matches the job. Permission design must be tested with a representative non-admin account rather than inferred from checkboxes.[1]
This operating model connects role engineering, two-factor authentication, restricted matters, external access, onboarding, moves, and departures. It complements the vendor-focused material in the ALLMSP Lawcus resource center, the industry context in Law Firm IT Services, and the broader safeguards in Cybersecurity.
ALLMSP coordinates Lawcus access, ownership, and security review from Lawrenceville for clients in Suwanee, across Gwinnett County and Metro Atlanta, and throughout Georgia, through one accountable in-house workflow from discovery and correction through testing, training, and ongoing support.
Key decisions at a glance
- Design custom Lawcus roles around job duties and segregate user management, accounting, reporting, intake, workflow, and matter permissions where the firm can do so.
- Require and verify two-factor authentication through an owned enrollment and recovery process, do not assume that publishing a policy means every user completed setup.
- Review restricted matters, matter membership, client and co-counsel access, messages, and shared folders together because a role alone does not describe every record a person can reach.
- Use deactivation when attribution and reversible suspension matter, and understand that deletion replaces the removed user’s name with N/A on retained contributions.
- For planned departures, prepare record and responsibility transfers before cutoff. For urgent authorized removals, end access on time and track the unfinished handoff separately.
Build Lawcus Roles From Duties and Separation Requirements
Create a role matrix before inviting users. Across the top, list recurring functions such as intake, contacts, matters, tasks, interactions, workflows, intake forms, document and eSign templates, invoicing, accounting, reports, CRM reports, team activities, and user management. Down the side, list real job patterns: managing partner, practicing attorney, paralegal, intake specialist, billing staff, operations administrator, temporary worker, client, and co-counsel. Mark required access, prohibited access, approval authority, and the person who owns each role definition.
Reserve Admin for people who genuinely need broad organizational control. Lawcus describes Admin as the highest-access role and notes that custom roles can combine selected feature permissions, while some core permissions in default Admin and Member roles are not adjustable. Use custom roles for focused work where possible, especially when a person should not manage users, change workflows, design intake forms, view firm-wide reports, or operate accounting functions. An internal job title is not a permission boundary, the configured role is.
Test roles with realistic tasks and records. A test script should cover navigation, search, contact visibility, lead handling, matter creation, task assignment, reporting, templates, financial functions, and settings changes. Record both expected access and expected denial. If the firm uses IP restriction on a custom role, validate approved and unapproved network paths and plan for remote-work exceptions instead of treating the address list as a substitute for identity security.
- Assign a business owner, technical maintainer, purpose, included duties, prohibited duties, and review date to every Lawcus role.
- Keep user-management, accounting, workflow design, intake-form design, and firm-wide reporting permissions narrower than ordinary case work.
- Use named accounts, do not share a user identity among attorneys, assistants, contractors, or administrative shifts.
- Retest role behavior after Lawcus feature changes, custom-role edits, practice expansion, or a finding from an access review.
Protect Sign-In and Control Authentication Recovery
Lawcus supports two-factor authentication with a time-based code from an authenticator application. Make enrollment a verified onboarding step for every applicable internal user, not an optional instruction buried in a welcome email. The user should sign in, enable two-factor authentication, complete a fresh login, and confirm the result with the onboarding owner. Record completion without collecting the user’s seed, QR code, password, or live token.
Recovery needs equal attention. Lawcus’s current help article says a firm administrator may contact Lawcus support to disable two-factor authentication for a user. Define who may request that change, how the requester and affected user will be verified, who approves the exception, and how quickly two-factor authentication must be restored. A support-mediated bypass without a firm-side verification log can become an undocumented path around the control.[3]
Do not claim controls the tenant has not configured or the vendor documentation does not establish. Password manager use, workstation security, email-account protection, device encryption, patching, and safe browser sessions remain part of the surrounding control environment even though they are not Lawcus role settings. Review connected email, calendar, storage, accounting, and automation accounts because access through an integration can persist as a separate dependency during an incident or departure.
- Require a successful post-enrollment login and retain only the completion record, date, and verifier.
- Create a two-factor recovery runbook with identity checks, authorized requesters, approval, vendor contact path, and re-enrollment deadline.
- Protect the user’s primary email and authenticator device because both influence invitation and recovery risk.
- Include connected applications and API tokens in access reviews, incident containment, and departures.
Test Matter, Client, Co-Counsel, and File Exposure
Role permissions are not the whole access story. Lawcus’s current matter guide uses Set Visibility to Private and Make Private for restricting visibility. It warns that at least one member, such as the responsible timekeeper, must remain on the matter so it stays accessible. Record who approves private visibility and membership, then test search, lists, tasks, calendars and files with approved accounts that should and should not have access. Absence from one screen is not sufficient evidence.[4]
External participation requires its own checklist. Lawcus describes Client users as limited to tasks, documents, and messages related to assigned matters, while Co-counsel users receive limited matter access for shared work. The vendor also notes that documents uploaded or messages sent by client users through the Client Portal are visible to everyone added to the respective matter. Before inviting anyone, verify the correct contact, matter, role, internal sponsor, permitted folders, expected end date, and communication expectations.
File sharing must be tested at the content level. Lawcus documents that a matter must first be shared with a client user before a folder can be shared, and the folder-sharing action can target selected client users or all users. Use a harmless sample file to confirm what each external account can open, upload, download, or discuss. Remove test content, record the result, and never assume that a restricted matter automatically corrects an overly broad folder selection or recipient list.[5]
- Maintain a sensitive-matter roster with sponsor, members, role, reason, approval, start date, and review or end date.
- Test restricted-matter visibility through search, lists, dashboards, tasks, calendars, reports, interactions, and files.
- Review client and co-counsel access after milestones, team changes, representation changes, and closure.
- Use non-sensitive test files and accounts to validate folder sharing before placing confidential material in a portal workflow.
Run Joiners, Movers, Leavers, and Reviews as One Lifecycle
For a new user, verify the email address, assign the approved role, send the Lawcus invitation, complete two-factor enrollment, and test required access. Grant matter membership only from an authorized list, then connect integrations according to job need. Capture the sponsor, start date, role, matters, external relationships, equipment, and training completion in one onboarding record so future reviewers can explain the starting state.
When a new role includes intake work, use the Lawcus intake-to-matter workflow guide to test a harmless lead through the handoff. For a departing integration owner, use the Lawcus integrations and reporting control guide to map the connected workflow and its replacement owner.
When a person changes duties, compare the old and new role matrices, remove obsolete matter membership and retest the required tasks. For a planned departure, inventory open matters, leads, deadlines, calendar events, documents, client communications and connected services before the effective time. For an urgent authorized removal, do not delay deactivation to finish that inventory. Remaining authorized owners must recover the work and record any gap.
Lawcus distinguishes deactivation from deletion: deactivation ends system access while retaining the user’s name on contributions and can be reversed; deletion replaces that attribution with N/A on retained contributions. Use deactivation for the immediate cutoff when appropriate, then make any deletion decision separately under the firm’s retention requirements. Record the actual account state and scope of verification; the account-management article does not establish how every active session, API token or third-party authorization is invalidated.[2]
Review users, roles, matter memberships, integrations and two-factor completion at least quarterly and after a significant personnel change or incident. Record a keep, change, deactivate, delete or investigate decision and its owner rather than closing a review without an outcome.
Worked example: urgent Lawcus cutoff with an unfinished matter handoff
Hypothetical example: a paralegal leaves at 14:00 with two open matters, a filing task and a connected calendar. The firm authorizes immediate access removal. These are acceptance checks, not a report of a client engagement.
| Checkpoint | Action and owner | Evidence needed before closure |
|---|---|---|
| 14:00 authorized cutoff | An authorized administrator deactivates the named Lawcus user at the approved time. Do not wait for the two matters to be reassigned. | Record the approval, execution time and actual account state. Escalate any uncertainty about remaining access. |
| Open legal work | The responsible attorney accepts both matters and checks the filing deadline; a remaining authorized user takes the task. | Each matter/task has a named owner and the attorney confirms the deadline. Do not substitute a blanket “all transferred” note. |
| Connected calendar and files | The integration owner checks the connected service and retained matter contributions separately using the supported service procedure. | Record which connections were checked and any unresolved authorization. Deactivation alone is not proof of token or session invalidation. |
| Retention decision | Keep the deactivated record while the firm decides its retention requirements; deletion is a separate approved action. | Attribution remains available as documented. No deletion is needed merely to finish the urgent cutoff. |
Official product documentation and ALLMSP resources
Frequently Asked Questions
What default user roles does Lawcus provide?
Lawcus documents Admin, Member, Client, and Co-counsel roles. Admin has the broadest organizational authority, Member supports internal legal work, Client and Co-counsel provide limited participation associated with assigned matters. Validate the actual configured behavior before relying on a role name.
Can a firm create custom roles in Lawcus?
Yes. Administrators can create custom roles and select feature permissions such as accounting, reports, contacts, leads, matters, workflows, intake forms, templates, tasks, interactions, and user management. Custom roles can also include IP restriction, which should be tested against the firm’s real work locations.
Can every permission be removed from the Lawcus Admin and Member roles?
No. Lawcus says certain core permissions on the default Admin and Member roles cannot be unticked. Use a custom role when a person needs a narrower duty set than those defaults allow.
Does Lawcus support two-factor authentication?
Yes. A user can enable two-factor authentication with a supported authenticator application and then supply a time-sensitive code at login. Firms should verify enrollment and maintain a controlled recovery procedure rather than merely asking users to turn it on.
How is Lawcus two-factor authentication recovered if a user loses the authenticator?
The Lawcus help center says a firm administrator can contact Lawcus support to disable two-factor authentication for a user. The firm should define authorized requesters, identity verification, approval evidence, and a prompt re-enrollment deadline for that recovery path.
What is a restricted matter in Lawcus?
Lawcus’s current matter guide calls the control Set Visibility to Private, followed by Make Private. Keep at least one appropriate member on the matter so the firm can still find and manage it, then verify access with approved test accounts. Private visibility, the role’s feature permissions and portal/file recipients need separate checks; changing one is not proof that every related sharing path was corrected.
Who can see client-portal messages and uploads in Lawcus?
Lawcus states that documents uploaded or messages sent by client users through the Client Portal are visible to everyone added to the respective matter. Review matter membership and recipient expectations before using the portal for sensitive communications.
What is the difference between deactivating and deleting a Lawcus user?
Deactivation removes Lawcus access while keeping the user’s name on retained contributions; it can be reversed. Deletion keeps contributions but replaces the removed user’s name with N/A. For an urgent authorized departure, deactivate at the required cutoff time and let the remaining authorized team finish the handoff. Do not keep access open merely to decide whether deletion is appropriate.
What should a Lawcus offboarding checklist include?
Record the authorized cutoff time, administrator and account action first. For planned departures, prepare the matter, lead, task, calendar and client-responsibility handoff in advance; an urgent authorized cutoff must not wait for it. Then reconcile open work, connected applications and recovery dependencies under remaining authorized owners. Keep unresolved items explicit, and verify each separate service rather than assuming Lawcus deactivation revokes every token or session.
How often should Lawcus access be reviewed?
Perform a structured review at least quarterly and after departures, role changes, sensitive-matter events, or incidents. Require a documented keep, change, deactivate, delete, or investigate decision for users, roles, matter memberships, external access, integrations, and authentication status.
