---
alias: user-guide-create-protocol
description: "Create a new Protocol instance by defining its name, type, scope, and state flow with associated parameters and dispositions"
---

# Create Protocol

:lock: Protocol.**Create**

## Overview

This operation is used to create a new **Protocol**.

## Setup

No special setup is required other than to meet the preconditions of the transaction.

## Preconditions

* The **Protocol** name must be provided and must be unique.

## Sequence of Steps

{% include-markdown 'includes/pages/info_creating_versioned_entities.md' %}

### Step 1: Change Set

1. Select an existing Change Set or select Create to create a new **Change Set**. If configured to support implicit **Change Sets**, it is also possible to check the option Use Automatic Change Set.
2. Optionally, select an Approval Role.

### Step 2: General Data

1. Provide a name for the **Protocol**.
2. If you are creating a new version, the revision that was selected when you started the process will be the revision to which this version will be associated. If you are creating a new entity or revision (with a new version associated to it), provide a name for the revision or it will be automatically generated for you. For more information, see the Naming section of [[revisions-index#naming]].
3. Optionally, enter a description.
4. Select the **Protocol** type. The list of possible values is taken from the [[protocoltype-lt]] lookup table.
5. Select the scope of the **Protocol** - defaults to General.
6. Select the **Protocol** severity. The list of possible values is taken from the [[protocolseverity-lt]] lookup table.
7. Optionally, add the following data:

      * **Default Owner** - reference to an existing **Employee**.
      * **Root Cause Source** - a lookup table to be used to select root causes.
      * **Overrides**
        * **Allow inhibit overrides** - if `true`, the options Default Inhibit Move from Step and Default Inhibit Ship defined at the protocol are simply default because you can change them when opening each new **Protocol** Instance.
        * **Allow state role override** - if `true`, you can override the protocol state role when changing the state of a **Protocol** Instance.
      * **Options**
        * **Default Inhibit Move from Step** - if a material is associated with a **Protocol** Instance, that material cannot be moved to the next step while the **Protocol** Instance is not closed or terminated (defaults to `false`).
        * **Default Inhibit Ship** - if a material is associated with a **Protocol** Instance, that material cannot be shipped while the **Protocol** Instance is not closed or terminated (defaults to `false`).
        * **Remove Terminated Materials** - each **Protocol** Instance can be associated with several materials; if meanwhile one material is terminated for any reason, the material will be removed from the **Protocol** Instance (defaults to `true`).
        * **Terminate on Zero Materials** - each **Protocol** Instance can be associated with several materials; once you disassociate all those materials, the instance will be automatically terminated (defaults to `true`).
        * **Default Auto State Change Behavior** - defaults to None. If the value is None, then no action is needed, otherwise:
            * Automatic - after evaluation of the conditions to change the state or close the **Protocol** Instance, it will automatically change or close. If there is more than one next state possible, the system will ask what is the new state and will automatically change it.
            * Prompt No - after evaluation of the conditions to change the state or close the **Protocol** Instance, you will be asked to change or close the **Protocol** Instance automatically (defaults to No). If there is more than one next state possible, the system will ask what is the new state. If you chose yes, the system will change the state or close the **Protocol** Instance.
            * Prompt Yes - similar to Prompt No, although in this case the default is Yes.

      * **Notifications**

        * **Send Email to the Owner and Role** - if `true`, whenever a **Protocol** Instance is created, the system will send an email to the Owner (if defined and has a valid email), to the Initiator (if defined and has a valid email), and to the distribution list of the Role (if any and has valid emails separated by a semicolon). The email has the **Protocol** Instance name, date/time, and list of materials and associated materials (if any).
        * **Send Notification to the Owner and Role** - if `true`, whenever a **Protocol** Instance is created, the system will send a notification to the Owner (if defined), to the Initiator (if defined), and to **Protocol** State Role (if defined). The notification shows the **Protocol** Instance name, the System State and the **Protocol** State.

![Screenshot showing a UI with options for creating a protocol, including "Create Protocol" and checkboxes for "Owner" and "Role".](images/create_protocol_step_one.png)

### Step 3: Dispositions

1. At the **Protocol** level, choose which actions are possible to be taken in a future instance by defining the following criteria:

      * **Allow Full Record Loss** - select a loss reason, predefined at the loss Reason list. The material will consequently be scrapped.
      * **Allow Rework** - select a Flow path, predefined as rework flow and a rework reason from the step Rework Reasons' list. The return path will be automatically filled based on the Go to Flow that was selected.
      * **Allow Temporary Off Flow** - select an Off Flow Path, predefined as Off Flow and an Off Flow Reason from the step Off Flow Reasons List. The return path will be automatically filled based on the selected departure point in the **Flow**.

![Screenshot showing a protocol disposition form with predefined off flow paths and reasons.](images/Protocol_Dispositions.png)

### Step 4: Parameters

1. Fill different **Parameter** details according to the type you selected. The different types are:

      * Boolean
      * Date Time
      * Decimal
      * Long
      * String

1. Select **Create** to complete the operation.

![Protocol Parameters](images/Protocol_Parameters.png)

### Step 5: State

1. When the **Protocol** is created, you can define its flow of states. The flow is not restricted to a unique unidirectional sequence; you can draw different paths. To build a flow of states, follow the steps below:

      * Drag all the states you need from the Shapes panel on the right-hand side of the screen and drop them in the main area. Define a Start and one or more Ends.
      * Once the states have been positioned, proceed to creating the connections; do so by pulling the arrows at each state shape.
      * Finally, drag and drop the Start and End shapes to the respective positions in the flow. You can have just one start but several ends.
      * Select the three-dot menu in each state and define the **Settings**.

    ![Diagram showing a flowchart with one state.](images/Flowchart_state1.png)

#### General Data

* **Name** - must be unique within the **Protocol**.
* **Description** - contains a description of the state.
* **Role** - should include the group of people who will perform each stage. The user needs to be associated with an employee object and, therefore, be included in the specified role for a stage.
* **Checklist** - has to be created prior to being associated with a stage. To validate the state, you must go through the checklist before changing the state.
* **Auto State Change Behavior** - by default, it will display the behavior defined in the **Protocol** options. However, you can change it at every stage.

![Diagram showing a flowchart illustrating the general data process and auto state change behavior settings.](images/Flowchart_General_Data.png)

#### Tasks

* **Allow Task Creation** - if `true`, you can create a new task. If `false`, the Task Creation State will be disabled.
* **Task Creation State** - tasks have different states: Created, Released, In Progress, and Completed. When defining the task creation state, you can choose Created or Released.
    * If Created, it needs to be approved to change to Released to be ready to be performed.
    * If Released, it does not need to be approved to be ready to Perform by the assigned user (owner).
* **Allow Task Release** - you can allow task creation as Created but you cannot allow its approval (to Release) at this particular state. However, this does not mean that the task cannot be approved at a subsequent step. To set this possibility, mark as `false`.

![Screenshot showing a flowchart illustrating the different states of task release and approval.](images/flowchart_tasks.png)

#### Dispositions

* **Allow Dispositions** - if `true`, you can create dispositions for the associated materials.
* **Dispositions Mode** (only configurable when Allow Disposition is set as `true`) - a disposition starts as Created, then Approved, and finally Executed. You can define which disposition stage you want to have at each protocol state, otherwise you cannot **Change State**.
    * **Allow** - you can create a **Disposition** for any associated material, although it is not mandatory.
    * **Approve** - in this state, it is mandatory that **Dispositions**, for all the associated materials, have been approved.
    * **Execute** - in this state, it is mandatory that **Dispositions**, for all the associated materials, have been executed.
    * **Require** - in this state, it is mandatory that **Dispositions**, for all the associated materials, have been created.
* **Requires Approval** - after the **Disposition** is created, it will be available for approval by the **Protocol Instance** owner. Only after this approval can it be executed by anyone who has state role permissions.

![Screenshot showing a flowchart illustrating the process of creating and approving dispositions in the protocol instance.](images/Flowchart_Dispositions.png)

!!! note
    You can only create Dispositions for associated Materials.

#### Parameters

You can enter some information in the **Parameters** section (example: you can choose which parameters you want to consider at each state of the **Protocol Instance**). Remember these **Parameters** need to be defined previously when you are creating the **Protocol** (see Step 4: Parameters above).

To select the parameters, follow the steps below:

1. Select the :material-plus: icon.
2. Select one of the **Parameters**, previously defined at the protocol creation stage. If the **Parameter** is a string, the type has to be defined by selecting one of the following options:

    * **Free text** - any text can be entered.
    * **Lookup table** - a list of option will be available when performing the **Protocol Instance**. To specify this list, you need to select a lookup table in the Source field.
    * **Query** - a list of options will be available when performing the **Protocol Instance**. To specify this list, you need to select a query in the Source field. Only queries with **Protocol** Parameter as Entity will be available.

3. Define if the **Parameter** is mandatory and if it is Read-Only (available for viewing but not editing).
4. Select **Save and Close** to complete the operation.

![Diagram showing a flowchart illustrating the parameters for a paver installation.](images/Flowchart_Parameters.png)