Lesson 4 of 7 · 5 min
Authoring SOPs and Checklists (Admin)
Walk through the admin resource builder — create a new SOP with a Markdown body or a Checklist with ordered items, assign topics and service types, and publish it to the team.
Authoring SOPs and Checklists (Admin)
Video coming soon
Lesson Notes
The admin resource builder lives at /resources and is gated on the backend to org members with the role OWNER, ADMIN, or PROJECT_MANAGER. Access is checked server-side — the page also checks client-side with useRoleGuard(['COMPANY', 'PROJECT_MANAGER']) and shows an AccessDenied component for anyone outside those roles. The page header reads 'Resources' with the description 'Author SOPs and checklists your field team uses on site.' Two call-to-action buttons sit in the top right: 'New SOP' (outline button with a book icon) and 'New Checklist' (filled button with a check-square icon). Both open the same editor dialog pre-configured for the chosen type.
The editor dialog adapts based on type. For an SOP, after the Title and Short description fields, a 'Markdown body' textarea appears with monospace font styling and placeholder content showing heading and list syntax. The body is required for SOPs — saving without it shows a 'SOP body is required' toast error. Admins should write the full procedure here using standard Markdown: ## for section headings, numbered lists for sequential steps, and **bold** for warnings or critical callouts. The markdown renders exactly as typed when team members open the resource.
For a Checklist, the body textarea is replaced by an 'Items' section with an 'Add item' button (plus icon, outline variant). Each item row contains a text input for the item label, a 'Required' checkbox, and a remove button (X icon). A GripVertical icon on the left of each row indicates drag-to-reorder intent, and items are submitted with their array index as sortOrder so the server preserves the order. Every item must have a label — saving with any blank label shows 'Every item needs a label.' Every checklist must have at least one item — an empty list shows 'Add at least one checklist item.'
Below the type-specific content, both SOPs and checklists share a Topics chip selector and a Service types chip selector. Topics (Pre-shoot, On site, Gear, Safety, Post-shoot, Handoff) are pill buttons that toggle on/off; active selections turn dark-filled. Service types (PHOTO, VIDEO, FLOORPLAN, DOCUMENT, VIRTUAL_TOUR, PROPERTY_WEBSITE, BROCHURE) work the same way. The hint under Service types reads: 'When set, this resource auto-surfaces on projects whose media types intersect. Leave empty to apply to all projects.' Leaving service types empty is the safe default for general-purpose SOPs and checklists.
At the bottom of the dialog is an Active toggle (Switch component) with the label 'Active' and the description 'Inactive resources don't show up on /portal/resources or the job detail page.' New resources default to Active. Clicking 'Create' validates all fields client-side first, then POSTs to /resources with the full payload. Success shows a 'Resource created' toast and the dialog closes, refreshing the admin list. The type field is immutable after creation — if you need to change an SOP to a Checklist you must create a new resource, since existing checklist runs are scoped to the original resource ID.
Key Takeaways
- The 'New SOP' and 'New Checklist' buttons open the same dialog pre-set for each type — the body field vs. the item editor is the key difference.
- SOP bodies use standard Markdown (headings, lists, bold); the rendered output is what team members see on the portal and iOS.
- Checklist items have a label (required), an optional description, and a Required checkbox — required items drive the progress counter field staff see.
- Topic and service-type tags drive filtering and auto-surfacing; service types left empty means the resource applies to all project types.
- The Active toggle lets you draft resources, hide them temporarily, or sunset old ones without deleting them and losing run history.