Skip to main content

What is Permitted States and How Are They Used?

Permitted States define which other states a record can transition to from a given state and how these transitions are presented to the user. This ensures that records in the system can only move to predefined states, preventing undesired or erroneous transitions and keeping the process flow under control.

Basic Usage Scenario​

A record (e.g., a document, nonconformity, or risk) can only transition to the Permitted States defined for its current state. This configuration ensures that records progress only according to a pre-approved and controlled flow. Each transition definition includes an action or button name that appears in the user interface. These buttons present the available transitions clearly and intuitively to users, improving user experience and ensuring the process flows according to rules. Additionally, Permitted States allow transitions not only within the same category but also between different State Categories. This flexibility makes it possible to manage complex workflows and different business processes within a single system.

💡 Tip​

By restricting transitions, you can ensure users follow only the defined steps. This increases the standardization and accuracy of your processes.

Steps to Define Permitted States​

Below are the step-by-step instructions for adding Permitted States to a state through the application:

1. Access the States Screen:​

  • Go to the "Function Design" section under "Administration" in the left menu.
  • Select the relevant record type and click "States" from the row actions.

2. Edit or Create a State:​

  • You can either edit an existing state or create a new one.

3. Open the Permitted States Section:​

  • In the state creation/edit screen, click on the relevant state and go to the "Permitted States" section in the panel that opens.

4. Add a New Transition Definition:​

  • In the Permitted States section, click the "+ New" button to add a new transition definition.

5. Fill in the Fields:​

  • Complete the required fields in the form that opens.
  • Click the Create button to save the Permitted State.

Key Fields for Permitted States​

The table below summarizes the main fields that must be filled when defining a Permitted State:
Required fields are shown in bold.

Field NameDescription
Target StateThe target state to which the transition will be made. This may belong to the same or a different category. It defines the direction and destination of the transition.
Action NameThe technical key internally used by the system to uniquely identify the action. It is not directly shown to the user.
Action TitleThe multilingual key that determines the label shown on the button or link in the UI that initiates the transition. Choose a clear and descriptive title for users.

⚠️ Warning​

  • In order to transition from one state to another, a definition must exist in the Permitted States section. This rule ensures the standardization and integrity of your processes. It is enforced to maintain system integrity and prevent unexpected behaviors.

  • Plan Permitted States transitions carefully according to your process requirements to design the correct workflow.

Example Use Cases​

  • Transition Within the Same Category:
    Allowing transition from “Draft” to only “Awaiting Info” and “Closed” states.
  • Transition Between Different State Categories:
    Defining a transition from a state in the “Review” category to one in the “Approval” category.
  • Multiple Transition Options:
    Offering users multiple transition options from a state (e.g., “Reject” and “Approve” buttons).

Simple Entity Structure of Permitted States​

Below is a simplified ER diagram showing the basic relationships of Permitted States: