Skip to content

Creating Procedures

How procedure formats, drafts, publishing, versions, categories, and ideas work.

What a procedure is

Procedures are the core content in Navis Docs. A procedure can be a freeform guide, a numbered checklist, a branching workflow, or a decision tree. Each team builds its own collection of procedures, and that collection becomes the team's knowledge base.

Procedures live inside teams and can be grouped by category so members can find the right guidance quickly. Admins usually create the categories first, then add procedures as the team's operating knowledge grows.

Choose a procedure format

Pick the format that matches the kind of work you are documenting. You can keep simple guidance lightweight, while giving high-risk processes more structure.

  • RAW: freeform rich text for policies, reference material, and narrative guides
  • STEPS: numbered steps for repeatable tasks, checks, and operational runbooks
  • FLOW: branching workflows where the next action depends on context or previous answers
  • YESNO: decision trees for questions that can be resolved through yes/no branches

Drafts and publishing

Every procedure has a draft version and, once published, a live version. Internally these are tracked as pendingVersionId and publishedVersionId.

Editing a draft never changes what members see. You can revise the pending version, review it with other admins, and publish only when it is ready. Publishing promotes the draft into the live procedure that members read.

Procedure statuses

A procedure moves through a small set of statuses during its lifecycle:

  • DRAFT: the procedure is being written and is not live for members yet
  • PUBLISHED: the procedure has a live version members can use
  • ARCHIVED: the procedure is retained for history but removed from everyday use

Version history

Each publish creates a new ProcedureVersion. The content is stored as contentJSON, which preserves the structured data for the chosen format.

Full history is retained, so teams can see how a procedure changed over time. This is useful for compliance reviews, operational learning, and understanding which version was live when a member used a procedure.

Organize with categories

Categories group procedures within a team. Admins create categories to match how members think about the work, such as onboarding, safety, customer support, incident response, or finance operations.

Keep categories broad enough to stay useful as the team grows. A small set of clear categories is usually easier for members than a long list of narrow folders.

Gather ideas from members

Members can submit procedure suggestions from the Ideas panel in the sidebar. This gives frontline users a simple way to flag missing guidance, unclear instructions, or processes that should be documented.

Admins triage ideas using these statuses:

  • NEW
  • IN_PROGRESS
  • COMPLETED
  • ARCHIVED

When an idea becomes a procedure, publish it like any other procedure so the team gets a stable live version and a retained version history.

Publish and notify

When you publish, you can choose rollout and notification options. These options can notify staff in-app, send email, and create a related news post depending on how the publish action is configured.

Rollouts are useful when a procedure needs acknowledgment or when a change affects compliance. For more detail, see Procedure Rollouts.

Suggested creation workflow

1. Pick the team and category

Start where members will look for the procedure. Choose the team that owns the work, then place the procedure in the closest matching category.

2. Select the format

Use RAW for flexible guidance, STEPS for checklists, FLOW for branching workflows, and YESNO for decision trees.

3. Write and review the draft

Build the pending version, check that each instruction is clear, and ask another admin or subject-matter expert to review high-impact procedures.

4. Publish when ready

Publishing creates a new version and makes it live for members. If the procedure needs attention from the team, enable the appropriate rollout and notification options before publishing.