Chuyển tới nội dung chính

Protocols

Protocols capture structured interaction history: notes, calls, meetings, emails, chats, demos, visits, decisions, escalations, and handoff context.

Route: /organizations/:id/protocols

In the product UI they appear as protocol entries attached to customers and related records—think of them as the team's written log of what happened.

Where Protocols Fit​

Protocols give the team an auditable, searchable record of an interaction.

Common examples:

  • A call with a guest, member, partner, lead, sponsor, or supplier.
  • A meeting note connected to a customer or project.
  • A demo or sales conversation with follow-up outcome.
  • A support handoff between shifts.
  • An email, chat, or note that should live beside the customer timeline.
  • A project or milestone update that explains why tasks were created.
  • A private internal note visible only to users with sufficient access.

Protocols answer "what happened?" Tasks answer "what needs to happen next?"

Protocol Fields​

Protocol records can carry:

  • Type: note, call, video call, email, chat, meeting, demo, or other.
  • Direction: inbound or outbound for email and call-style interactions.
  • Outcome: open, successful, follow-up needed, not interested, no response, or rescheduled.
  • Subject: short summary of the interaction.
  • Description: longer formatted notes.
  • Date: when the interaction happened.
  • Duration: minutes, shown for protocol types where duration is relevant.
  • Customer: the related customer, when created from the organization-wide protocol view.
  • Privacy: whether the protocol is private.
  • Documents/files: attachments associated with the protocol.
  • Tasks: follow-up tasks created together with the protocol.
  • Project and milestone: optional context when the protocol is logged from project workflows.

Protocol Types​

Supported protocol type values include:

  • note
  • call
  • videoCall
  • email
  • chat
  • meeting
  • demo
  • other

Some types support duration because they represent time-bound interactions. Notes and email-style records are usually about content rather than duration.

Outcomes And Direction​

Outcomes help teams scan history quickly:

  • open: still unresolved or not classified.
  • successful: completed positively.
  • follow_up_needed: follow-up work is expected.
  • not_interested: the contact declined or is not currently interested.
  • no_response: outreach did not receive a response.
  • rescheduled: the interaction moved to another time.

Direction is available for email and call-like flows:

  • inbound: the customer or external party contacted the organization.
  • outbound: the organization contacted the customer or external party.

Views And Entry Points​

Protocols are visible in multiple places:

  • Organization protocol list: all visible protocols for the active organization.
  • Customer detail tab: protocols for a specific customer.
  • Project detail tab: protocols linked to a project.
  • Milestone detail page/tab: protocols linked to a milestone.
  • Document detail: protocols linked to a document.
  • Timeline-style views where customer interactions are converted into general timeline entries.

The same protocol can therefore matter in several contexts. For support, use the customer, project, milestone, and document links to understand why a protocol appears in a specific view.

Creating Follow-Up Tasks​

When an interaction produces next steps, users can add tasks while creating the protocol:

  1. Log the call, meeting, email, or note as a protocol.
  2. Add one or more tasks with names, due dates, assignees, tags, and privacy settings.
  3. The protocol preserves the context, and the tasks appear in task views and related customer/project contexts.

This is the main handoff pattern for support and operations teams.

Privacy And Permissions​

Protocol navigation appears when the user can list or read protocols. Creating, editing, and deleting depend on protocol permissions. Protocol rows and actions can also be affected by the related customer's assigned/responsible context.

Private protocols are intended for sensitive internal context. If a user cannot see a protocol that another teammate can see, check:

  • The user's protocol list/read permissions.
  • Assigned-only scope.
  • Whether the protocol is private.
  • Whether the protocol is attached to a customer, project, or milestone the user cannot access.
  • Whether the user is looking at an organization-wide view or a filtered customer/project view.

Common Support Scenarios​

A protocol is missing from a customer timeline​

Check whether the protocol is attached to the expected customer. If it was created from a project or milestone context, it may be attached to the project/milestone but not to the customer.

A protocol appears in project context​

Protocols can link to projects and milestones. This is expected when the interaction is part of delivery work, not only direct customer history.

A protocol created tasks but the tasks are not visible​

Check task permissions, assigned-only task filtering, show completed filter, customer/project/milestone context, and task status.

Attachments are hard to find​

Protocol files may appear in protocol detail context and can also relate to document workflows. Check the document library and the related customer/project/document tabs.

Related concepts: Tasks, Customers.