A SwiftChecklist account is most effective when the right people can see and act on client submissions without everyone having full access to everything.
This guide covers inviting team members, assigning roles, configuring access, and setting up notification routing so handoffs happen without someone having to manually alert the next person.
Understanding team roles
Admin
- Full access to all settings, billing, integrations, and team management
- Can create, edit, and delete checklist templates and instances
- Can view and manage all client records and submissions
- Receives all notifications by default (configurable)
- Assign to: firm partners, practice managers, and the account owner
Member
- Can create and manage checklist templates and instances
- Can view and manage all client records (or restricted to specific ones, see below)
- Can review and approve submissions
- Cannot access billing settings or account-level configurations
- Assign to: intake coordinators, paralegals, accountants, and consultants who run the onboarding workflow
Reviewer
- Read-only access to assigned checklist instances and client records
- Can add internal comments and notes on submissions
- Can request changes or approve submissions (configurable — can be disabled so reviewers can only comment)
- Cannot create or edit templates or instances
- Cannot see client records not assigned to them
- Assign to: attorneys or partners who review intake packages but do not manage the workflow; audit or compliance reviewers; external contractors who need limited access
Inviting team members
From Settings → Team → Invite member:
- Enter the team member's email address
- Select their role (Admin, Member, or Reviewer)
- Add an optional note about their responsibilities (visible only to admins)
- Click Send invitation
The team member receives an invitation email with a link to set their password and access the account. Invitations expire after 7 days — use Resend invitation from the team list if a member has not accepted.
Configuring access restrictions
By default, Members can see all client records and checklists in the workspace. For firms where different teams handle different practice areas or client segments:
- Open the team member's profile from Settings → Team
- Click Access restrictions
- Toggle on Restrict to specific checklists
- Select the templates and instances the member should have access to
Restricted members only see the client records attached to their permitted instances. They cannot see or search for restricted records.
Use case example: A three-attorney law firm where each attorney's clients should only be visible to that attorney and the intake coordinator. Set access restrictions so each attorney sees only their assigned instances, while the intake coordinator has unrestricted access.
Setting default assignees on templates
To prevent submissions from landing in an unowned queue:
- Open the checklist template in the template editor
- Click Template settings
- Under Default assignee, select the team member who should own new instances created from this template
New instances created from this template will be automatically assigned to the designated team member. The assignee receives a notification when a client submits their checklist.
Default assignees can be overridden when creating a specific instance — useful for ad hoc cases where a different team member handles a particular client.
Notification routing
Good notification routing means the right person is alerted for the right event, without everyone receiving every notification.
Configure notifications at two levels:
Workspace-level defaults (Settings → Notifications): Set which events trigger notifications and who receives them by default. Workspace defaults apply to all instances unless overridden at the instance level.
Instance-level overrides: On any specific checklist instance, open Notifications to add or remove recipients for that instance only. Useful when a specific client requires oversight from someone outside the usual workflow.
Key notification events to configure:
| Event | Recommended recipient |
|---|---|
| Checklist submitted | Instance assignee |
| Document uploaded | Instance assignee or specific reviewer |
| Signature completed | Instance assignee and billing/operations contact |
| Payment received | Billing coordinator or operations |
| Checklist stalled (3+ days without activity) | Instance assignee |
| Change request completed | Instance assignee |
Avoiding notification fatigue: Do not route every event to every team member. Overnotification causes people to ignore the inbox. Route only to the person who needs to act.
The team member's daily workflow
For team members managing intake, the typical daily workflow:
- Open the Checklists → Dashboard and filter by Awaiting Review to see new submissions
- Review each submission, approve it, or send a change request with specific instructions
- Assign approved submissions to the working team member if not already assigned
- Check the In Progress filter for any instances that have been stalled for more than 3 days — consider sending a manual follow-up
For team members who only review (Reviewer role):
- Notifications arrive when a submission is assigned to them for review
- Open the instance, review the submission, and add comments or approve
- They cannot approve by default — configure Reviewer approval permissions in Settings → Team → Reviewer permissions if needed
Deactivating a team member
When a team member leaves the firm:
- Before deactivating: Review their active instances from their profile page. Reassign each instance to the appropriate team member using the Reassign button on the instance.
- Deactivate the account: Go to Settings → Team, open their profile, and click Deactivate. Their access is revoked immediately. Their submitted notes and activity history are preserved and attributed to their name.
- Archive their default templates: If they had templates assigned to them as default, update those templates to assign a new default owner.
Do not delete team member accounts if they have activity history — deletion removes all associated notes and history. Deactivation is the correct option for departures.
Continue with
- Workspace setup — configure workspace-level settings
- Build your first checklist — assign team members to templates
- Review and handoff — the internal workflow after client submission