Flexible States
This functionality allows you to configure the stages through which a task, site, network element, among others, can go through until it is completed. It will allow us to better reflect the life cycle of an activity, while collecting metrics for each step.
¿ What are flexible states ?
We will take as an example teams that manage tasks in the field, who need to know exactly what happens at each moment of the task, being able to also account for transfer times, effective work, closure, and more.
By default, there are 5 task states:
- Open
- In progress
- completed
- Completed with earrings
- On hold
- Cancelled
These stages are simple but very useful for most of the "quick" activities that exist in a project. However, if you want to identify an activity that can be interrupted for different reasons, or if it is in progress but in the final stage, it is not possible to do it just by seeing it in the "In Process" state.
The new flexible states functionality allows you to customize stage names and choose their behavior to reflect what is actually happening in the task. For example, a task may now be in the status "In Travel to Site", which gives us more information than just "In Process".
To go from one state to another we will use "transitions". The transitions will have the name of the action that takes us to the next state of the task. As an example, a technician may have the task in the "On Trip" status and from there choose two possible transitions: "I arrived at the site" or "Delay", in case for some reason, he had to deviate from his activity. The "Arrived at Site" transition will move the task to the "On Site" state; the "Delay" transition will move it to the "Delayed" state.
Transitions are the new ally to customize a task flow
Transitions also allow us to avoid paths to certain states. For example, a task in the "Working" status will not be able to go (if we configure it that way) to the "On Trip" status. You may have two possible transitions: that the job has finished or that it has been interrupted for some reason.
These processes provide consistency to the information, but also help to simplify the task of each technician. If the process is well defined, the technician will have among his options one that will reflect exactly what he is going to do.
Taking an installation task as an example, we could customize and reflect the process with the following flow:
Each new status will have an original "status type": Open, In Process, Completed, etc. That is, we will have several states of the "Open" type, but with different names. In the image above you can see three "Open" states: Created, Assigned, Taken.
View of a configuration of original states and their transition alternatives
Continuing with the example... the "In Trip" status is of the "In Process" category.
In order to simplify some system processes, such as required documents and other functionalities, we have allowed for the moment to have a single final or closing status; that is, a single status of type "Completed".
Each state, in addition to the multiple transitions it can have, can be configured with the "It is accessible from any state" property. This feature allows the state to be available from any of the process states.
As part of this change, we decided to consolidate the approval processes in setting up new statuses. Now everything is a state and the transition between one and the other may or may not have an approval process.
We hope that this functionality helps to improve the personalization and monitoring of activities to work more efficiently every day.
How to configure flexible states
In the configuration menu select "State streams"
There we can search for an existing one or create a new state flow:
Each status flow has the following data to configure:
- Name or title of that process
- Object Type: since it can be used for some type of system object
- Work area: It is possible that a status process is used only by one work area of the company and not by all.
- Default flow: If it is active, each time a new object of that type will be created, it will be assigned this state process
- Each type of object can have only one default state stream.
- Status: It must be in Confirmed to be able to be used in the different objects..
En el tab "Flujo" tendremos las etapas que participan en este proceso, con las siguientes opciones:
- In the "Flow" tab we will have the stages that participate in this process, with the following options:
- Stage: State name
- Stage Type: It is a type of status, which allows us to know when a task is finished or cancelled, regardless of its Stage name.
- Example, a stage can be called "Traveling to site", and we will assign it the stage type "Open", which will help us to know that the task is not yet in progress.
- Transitions: Lets us know from where or to where you can go from the selected state.
Una transición puede tener los siguientes datos:
- Nombre: Para indicarle al usuario una acción que le resulte más fácil identificar, por ejemplo "Iniciar Viaje", podría ser el nombre de la transición que lleve la tarea al estado "Viajando a sitio"
- Estado origen
- Estado destino
- Vallado geográfico: Si se activa o no el geofencing para ese estado (Esta opción no está disponible actualmente)
- Transición de ejecución automática: Se ejecutará la transición automáticamente al llegar al estado origen.
- Esto es útil para poder disparar automáticamente procesos de aprobación, por ejemplo
- Transición preferida: Indica al usuario cuál es el "camino feliz" de la actividad. Por ejemplo, la transición preferida podría ser "Iniciar Viaje", pero puede haber otras transiciones que sean de "Obra suspendida", o "Posponer inicio", que no serían las prioritarias a mostrarle al usuario.
- Requiere aprobación: Si para pasar del estado origen al destino, necesita un proceso de aprobación.
¿ How to set up an approval process ?
If the transition has the Require approval option activated, a process of different validations can be configured to move from one stage to another.
For example, an approval process could be used to indicate that the task is indeed complete, but the field technician needs an OK from the Project Manager to advance the task to "Done".
- Condition: It is the type of validation that is needed, you have several options between
- All approved: each group must give their ok to advance
- Anyone approved: if there is an Ok, move on
- First approval: The first to approve (if there are several stages in parallel) advances the transition
- First rejection: If there is a rejection, the transition is canceled and returns to the indicated Rejection status in the "Reject to status" field configured in the transition.
Once our entire process is configured, we can change its status to Confirmed, and thus start using it in our tasks, sites, network elements and clients, among others.