Using the SOP Reader Effectively in the Field

SOPs are designed to be opened on a phone while you are at a property. The web portal at /portal/resources is mobile-optimized: the card grid collapses to a single column, the search bar is full-width with a magnifying-glass icon, and the topic filter pills scroll horizontally so they don't wrap. On iOS, ResourcesView in the More drawer mirrors this experience with an inset-grouped list and a sheet-based detail view that renders the Markdown body using Swift's AttributedString, which handles inline formatting like bold and italics natively.

To find the SOP you need on-site, the fastest workflow is to tap the most relevant topic pill — usually 'On site' or 'Gear' — then scan the shortened list by title. If your org has more than a handful of resources, use the search bar; it searches title and description simultaneously with no delay. Once you open an SOP, the body is fully selectable and copyable, which lets you paste a specific address or reference number if needed.

SOPs render headings as larger bold text, numbered lists as sequential steps, and bullet points as indented lists. This means well-authored SOPs are genuinely readable on a 390px iPhone screen — the prose wraps cleanly and section headings create natural navigation landmarks. If an SOP body looks like raw Markdown syntax (asterisks, pound signs), that is a signal the admin may have saved it with a rendering issue — contact your admin to verify the body was saved correctly.

One important limitation: SOPs are read-only. You cannot annotate, comment on, or mark an SOP as 'done' from the SOP reader — that concept belongs to checklists. If your team needs to record that a procedure was followed on a specific job, the correct tool is a Checklist template, not an SOP. Use SOPs as reference material and checklists as accountability records.