The Protocol Editor uses a versioning system in order to keep track of all the relevant changes made to a graph, capturing relevant information on who edited it, changes made, and when were they were made. 

The versioning system works in the following way:

1. Draft 

• When in draft mode it means that a graph is not released and is not active. Call takers will not have access to it in Triage. 

• As a draft, the graph can be edited at any time since the graph is not released.

• A draft can be released.

2. Released 

• When a graph is released, you can still edit the description of the released version of the graph.

• However, the version number will be locked and the graph contents will no longer be editable.

• If you want to make changes to a released graph, you can do so by creating a draft of the released version.

  • This will create a workable draft copy of the selected graph and where you can then start working and editing it.

3. Active 

• Any released graph can then be activated and become the default graph to be used in Triage. 

Delete options

• It is possible to delete either a version of the graph or the entire graph. 

• To delete a single version, you can click on the 3-dots icon next to the graph to open the menu and find the delete button at the bottom of the menu.

• To delete a graph, you can do so in the graph settings menu.

• There is a 2-step confirmation, so the system will ask you to confirm the action before actually deleting the graph.

⚠️ There is no trash container, so any deletions are immediately permanent.

You generally will want to start with a home branch. This will form the basis of your graph, and will be will where all calls will start. Each branch will then represent a single protocol (complaint or incident type). You could in theory build your entire protocol set in a single branch but this would be exceedingly hard to manage which is why we recommend multiple branches be used.

View nodes are the primary nodes and where all the custom blocks live. Link portal nodes are covered separately in a later section. Detection trigger nodes are still in testing, and training material for these will be available later. 

Content Blocks vs Protocol Blocks

• Content blocks are those that have no impact on the protocol flow, meaning the flow will continue down the set flow regardless of call taker action. 

  • Action: - A button (clickable element) allowing the call taker to send a specific type-code, indicating the dispatch of a specific set of resources in accordance with your organization system.  Actions are elements that communicate with integrations such as CAD software. By default, the Action will be triggered by the call taker manual click. Alternatively, the Action button can be set to fire automatically, as soon as the node appears. This can be set by ticking the triggerOnMount box, in the block attributes field.

  • Paragraph: Informative text block containing read-only text for the call taker. Paragraph blocks can be made collapsible by ticking the appropriate box. In order to be collapsible, the text in the paragraph block needs to be divided into 2 paragraphs, or more.

  • Flow Value Collector:  Block designed primarily to automatically collect desired values (when and if they are selected by the call taker in Triage) and provide an overview of those values. Secondly, this block can also be edited manually by the call taker if s/he wants to add extra information. You can learn more about flow value collectors and how to use them in the separate flow value collectors section further down this page. 

• Protocol blocks are those whose content is used to build the protocol flow. Unlike content blocks, protocol blocks require the call taker to make a choice/provide an input of some sort in order to proceed to the next node. The content of these blocks is coded into variables that can then be used to form the logic expressions.

  • Simple Text Input: Input block, for call taker to insert a single line of text.

  • Multiline Text Input: Input block, for call taker to insert multiple lines of text.

  • Select: Input block, by default, it is a single-select block allowing the call taker to select ONLY ONE option among the several ones provided. The block can be turned into a multi-select (allowing the selection of multiple options) in the Protocol Editor by using the dedicated switch in the sidebar, once the block has been selected.

⚠️ To save a graph you must set both a start node for the graph and a start node for the branch. Attempting to save without both will return an error. You can always change these later as needed. 

Link portal nodes are most commonly used to link branches to each other. If you are following the standard graph structure we recommend with a starting home branch, most of these link portal nodes will be required after the initial complaint report so that the call taker can proceed down the exact branch they need. Keep in mind that the more nodes a graph contains the larger the drop down list will become. To make selection easier you can start typing to search through the drop down options. You can also see the branch the node is in to the right of the name in brackets. 

⚠️ A branch must have a view node before you can link to it. 

Component Blocks and the Component Library

• Component Blocks are custom content blocks that can have multiple instances within the same graph and their data content and style/ format are always updated and synced across all instances according to the latest edits made to any of them. 

  • Both the content of the node and the data entered by the call taker during a call is synced across all the component blocks. This is highly useful for blocks, such as demographics, that you want to allow the call taker to enter data into in multiple locations. 

  • If a content block contains variables that are used in logic gates, such references will NOT be affected when the block is turned into a component. 

  • The context menu when right clicking for a component is nearly the same as that of a normal content block, the only difference is that a component can be exploded. 

    • Exploding a component means converting it back to a normal content block.

    • If a component instance contains variables that are used in logic gates, such references will be affected when the component is exploded. They will become missing references requiring correction. 

• Component Library is where component blocks are stored. From the library you can take the following actions: 

  • Edit the content of any component block. Double clicking on the component will open up the component editor.

  • Rename a component. By default the system generates a unique ID for each component, but that can be changed to a more meaningful name using the NAME field. It is highly recommended you update the name as soon as a block is made into a component, to prevent confusion. 

  • Delete a component from the library. When you delete a component from the library:

    • If there are zero instances of that component in the graph, it will simply delete it from the library. 

    • If there are 1 or more instances in the graph deleting a component from the library will explode all the existing instances of the component. In other words, the existing instances are NOT deleted but turned into normal blocks. 

    • If any logic gate is referencing variables that were contained in the deleted (exploded) component, such variables will become missing variables in the logic expression causing the logic to fail. The variables will need to be updated before the flow is once again functional. 

  • Locate all the instances of a component. There is a section called 'Instances' showing/locating all component instances in use. There it is possible to see all the instances of a component, once selected from the library.

    • Clicking on one of the instances will locate it and take the user to the view node on the canvas in which the instance is placed.

  • Using the dedicated search bar, it is possible to filter instances by typing in the branch name and to see all the relevant instances

⚠️ To save a graph you must set both a start node for the graph and a start node for the branch. Attempting to save without both will return an error. You can always change these later as needed. 

Setting up a Flow Value Collector is quite simple and it can easily be tested in Triage to double check it works as expected.

• A collector is able to collect values that belong to the same graph where the collector is located.

• It is possible to have multiple collectors within the same graph, as long as they all have a unique name.

• It is designed to collect and store values as soon as they are selected (entered) by the call taker during the call in Triage. 

• Typically these collected values such as demographics, type codes, and problem descriptions etc. are then sent to the CAD via an integration

The necessary steps to do so are the following:

1. Create a dedicated view node to host the flowValueCollector

• It is important to highlight that, although it could potentially be placed anywhere, the primary purpose of this block it to collect desired values to provide an overview of certain parameters to the call taker. 

• Therefore, this block it is best placed in a view node that has no links to other nodes and pin it, so that is always accessible from the pinned items view in Triage. That being said, you can also host the flowValueCollector in an existing viewnode that is a part of the flow, if you want the call taker to see the contents at a set point in the flow. 

2. Pin it to Triage (if you want the collector to be pinned in the Triage call taker view)

• In the section dedicated to the 'Node Info' in the sidebar, there is the option to pin the viewnode to Triage by simply ticking the box. 

• If you have chosen to host this block in a view node that is not connected to the flow, you must pin it to Triage for the call taker to see it, otherwise the block will be hidden. 

3. Name the view to quickly identify it in Triage

• It is also important to give a proper 'publicly visible' name to the view, so that it will be clear what this pinned view is about when opened in Triage.

• To name the view, first, make sure the correct element is selected. If you are in doubt, from the sidebar you can double-check that the view is selected and colored in light blue.

• Then go to the 'EDIT CONTENT' section in the sidebar and give it a proper name. 

• The node has of course to be populated with at least one flowValueCollector block. It is possible to have more than one collector in the same node.

• The same view can be populated with other block types as well, for example a 'Paragraph' or text block, to add extra information for the call taker so that s/he will clearly understand what kind of values each collector is collecting.

4. Name the flowValueCollector block

• In case you have 2 or more flowValueCollector blocks, make sure they are all named differently. To make sure the right element is selected you can:

  • Double-check that the desired flowValuCollector block is highlighted in light blue

• Once selected, enter the collector name in the add label text field. 

  • The name given to each collector block in the name field is not visible to the call taker but it is nonetheless important as it is used to build the value collection logic. 

5. Add the flow value collector to the blocks you'd like to track

• At this point, the collector has been set up and it is ready to collect values. We just need to tell it what values to look for.

  1. Select the node containing the values you want to collect, and press 'EDIT CONTENT'

  2. Select the block or optionally one of the select values (the options) that you would like to monitor and collect.

     1. It is possible to collect values from a multi-select block as well as values from a single-select, simple text, multi-line text, and date select block. For select blocks you can choose to collect values from the entire block or only certain selections by click the entire block or individual options and then selecting the flow value collector. If you add the attribute to the entire block, you don't need to also add the custom attribute to each option.  

  3. Once you have selected a value that you want the collector to collect, click the 'ADD COLLECTOR' button.

  4. Choose the appropriate option from the drop down. 

  5. Validate and save the graph.

• You can add as many collectors to blocks as you would like. 

6. Test it in Triage or Graph Preview to make sure it has been set up correctly

• Once the collector and the necessary values logics have been set up correctly, it it time to test the relevant graph in Triage to see if the collectors are working as expected. You can also test in Graph Preview. 

• Use the 'CREATE A NEW INTERVIEW' to start a new session and test the collector functionality. Make sure you choose the correct graph and version. 

Smart Comments are a feature that allow you to send additional information, mostly in the form of additional symptom information, directly to the dispatched resource. You will first need to create a flowValueCollector by following the above instructions. Once that is complete you can build the Send Smart Comment Action button by following the below steps: 

1. Create an Action block 

• You will want to create this somewhere the call taker has access to, so either in a node that is pinned in Triage or a node that is a part of the flow. 

• Name the action smart-comment-trigger.

  • It must have this exact name to function. 

• For content, name it Send Smart Comment or something similar that will make sense to the call taker.

• It is highly recommended that you make this action block a component so it can be easily replicated elsewhere without fear of typos. 

2. Add a custom attribute to the flowValueCollector 

• Locate the flowValueCollector you want to send from.

• Add a new custom attribute and type the following 

  • For the key: smart-comment

  • For the value: 1

For Smart Comments to function additional back end integration work is required. Please coordinate this with your Corti representative. 

• use H1, H2 to have different types of headers

• use B to make selected text bold, alternatively use `ctrl` + `b`

• use I to make the selected text italic, alternatively use `ctrl` + `i`

• use U to underline selected text, alternatively use `ctrl` + `u`

• use S  to strike-through selected text, alternatively use `ctrl` + `shift` + `x`

• use 🖋 to highlight the selected text in a specific color that is possible to chose from the color picker

• use • to add an indented bullet list

• use 1. to add an indented numbered list

• use 👁️ to hide selected text, the hidden text will not be displayed in the Triage interface to the end-use

• use 🔗 to add/remove a link to the selected text

  • ⚠️ You must include the https:// in the url otherwise the link will not work

• use 🗨️ to add/edit a note to the selected text (hoovering over the text will display a popup with the desired information)

Although they might sound similar, saving and validating a graph are two different actions and they have dedicated separate buttons. The validation tool of the graph looks for and highlights critical issues and warnings that might need to be fixed, as they might prevent the graph from working as intended. 

Most common issues are: 

• Logic gate has no end target: One or more logic gates have been created but they are not linked to any node, therefore the flow will reach a dead and show no next card, if those logic gates are triggered by the user. Locate the logic gate in the node and link it to the next node in the protocol sequence. 

• Missing reference: Usually, it means that some options (variables) have been moved or removed from inside an existing node's content block, and as a result the corresponding logic gate cannot find the variable(s) anymore. Review the variables and ensure they are correct. 

• Node has no content: You forgot to add a block to your node. Either update the node or delete it. 

• Node has no inputs: This means that a node but is not linked to any flow. Connect the node to the flow. If the node contains a flow value collector, that might actually be desired as it might not need be linked to the flow.

It is important to keep in mind that:

• The validation tool is checking all nodes, not just the nodes belonging to the critical path. Thus, validation can return errors related to standalone nodes, that do not impact the actual protocol flow such as pinned nodes.

• It is possible to save a graph to the backend even if the validation reports issues that need to be fixed in order to make the graph fully functional.

• Other than missing references, the validation tool does not check the syntax of the logic gates. If there are misspellings or syntax issues, they are not highlighted by the validation process.

• You can click each validation error to be redirected to the specific node where that issue is located. 

• The granular breakdown can be collapsed into a shorter list displaying number of issues/warnings by category. 

• Just because a graph returns validation errors does not mean it won't function or isn't correct.