name and iconName.
Each step has its corresponding data parameters.
It is possible to configure a step with no approval order.
If the order needs to be followed, configure the orderedPolicies variable. Otherwise, just use the variable `policyNames
It is possible to configure a step that has dependence on other(s), both approval and reproval dependencies.
For aproval dependencies, you will set variable stepIdsDependencies which is and array of step ids as strings.
For reproval dependencies, you will set variable stepIdsReprovalDependencies which is and array of step ids as strings.
Ex:
- It is only possible to measure step B, case by step A, this measure approved by all participants. In this case, step B has dependence on step A
- It is only possible to measure step C, if steps A and B are approved by their respective participants. In this case, step A depends on step A and B.
- It is only possible to measure at step E, in case step D is reproved (a reproval of a participant is enough) In this case, step E is dependent on reproval of step D.
- It is only possible to measure at step E, in the case of step D and C, there are reprovadas (just one reproval of a participant in each step) In this case, step E is dependent on the reproval of steps D and C.
stepIdsDependencies is an array of ids of other steps, defined when there is a dependence on reproval
A variable stepIdsReprovalDependencies is an array of ids of the other steps, defined when there is a reproval dependency
Deadlines
Each step can have a deadline. The deadline is usually in days. But can also be in hours or weeks. Checking if a step is delayed only makes sense when analysing theaction table on the measurements object.
Deadline Types and Units
Deadlines can be configured in different time units:- Hours: For urgent or time-sensitive steps requiring quick action
- Days: Most common unit for standard business processes
- Weeks: For long-term processes with extended timelines
Deadline Scenarios
1. Single Policy Group Deadline
If a step has only one policy group and a user from that group performs a WRITE_DATA action, the step becomes delayed when the deadline period expires without any APPROVAL or REJECTION action from the same group. Example: Step A with policyName “P1”, deadline of 24 hours- User from P1 writes data at 10:00 AM
- Step is delayed if no approval/rejection occurs by 10:00 AM next day
2. Multiple Policy Groups Deadline (Sequential)
If, for example, there’s a measurement for Process 1 with steps A with policyNames “P1” and “P2”, with a defined deadline of 2 days, and user P1 has already measured step 1 on measurement X, the step is delayed when 48 hours have passed after the WRITE_ACTION of step 1 on measurement X and no other action by users form group P2 has taken place. Either be it an approval or rejection action.3. Multiple Policy Groups Deadline (Parallel)
For steps requiring actions from multiple policy groups without ordered dependencies, the deadline applies to the entire step completion. The step becomes delayed when:- All required policy groups must complete their actions within the deadline period
- Delay occurs if any group fails to act within the deadline timeframe
- WRITE_DATA occurs at Day 0
- Step is delayed if any group (P1, P2, or P3) hasn’t approved/rejected by Day 3
4. Ordered Policy Groups Deadline
WhenorderedPolicies is configured, each policy group has its own deadline window:
- First group (orderedPolicies[0]) has full deadline period
- Subsequent groups have remaining time from previous actions
- Step becomes delayed when any ordered group misses their action window
- P1 must act within 4 days of WRITE_DATA
- P2 must act within remaining time after P1’s action
- If P1 acts on Day 2, P2 has 2 days remaining
5. Dependency-Based Deadlines
Steps with dependencies inherit deadline pressure from parent steps: Approval Dependencies: A step cannot be measured until all dependent steps are approved- Deadline pressure cascades to dependent steps
- If parent step is delayed, dependent steps may become time-critical
- Deadlines apply from the moment the reproval dependency is satisfied
- New deadline window starts when reproval occurs
6. Rolling Deadline Extensions
In complex workflows, deadlines can effectively extend through step dependencies:- Each step maintains its own deadline
- But effective completion time depends on dependency chain
- System tracks both individual step deadlines and overall process timeline
7. Escalation Deadlines
Steps can have escalation rules where delays trigger:- Automatic notifications to supervisors
- Escalation to higher authority groups
- Process suspension or intervention requirements
Deadline Calculation Logic
Deadlines are calculated from the timestamp of the most recent WRITE_DATA action on that step within a measurement. The system checks for delays by:- Finding the latest WRITE_DATA action for the step in the measurement
- Adding the deadline duration to that timestamp
- Checking if required APPROVAL/REJECTION actions occurred before deadline expiration
- For multiple policy groups, ensuring all required groups have acted
Deadline Monitoring
The system continuously monitors:- Individual step deadline compliance
- Policy group action completion
- Dependency chain status
- Overall process timeline health
- Step accessibility (delayed steps may block dependent steps)
- Process reporting and analytics
- Escalation workflows
- Compliance tracking
Relationship Graph (bullets)
- Step.process -> Process (Step N — 1 Process) [fk: processId -> id] (onDelete: Cascade)
- Data.step -> Step (Data N — 1 Step) [fk: stepId -> id]
- Parameter.step -> Step (Parameter N — 1 Step) [fk: stepId -> id] (optional) (onDelete: SetNull)
- OptionItem.parameter -> Parameter (OptionItem N — 1 Parameter) [fk: parameterId -> id] (optional)
- AdvancedOptions.parameter -> Parameter (AdvancedOptions 1 — 1 Parameter) [fk: parameterId -> id] (optional) (unique: parameterId)
Measurement
Measurement.process → Process (Measurement N — 1 Process) [fk: processId → id] Measurement.actions → Action (Measurement 1 — N Action) [fk: measurementId → id]Action
Action.step → Step (Action N — 1 Step) [fk: stepId → id] (onDelete: Cascade) Action.measurement → Measurement (Action N — 1 Measurement) [fk: measurementId → id] (optional)Cardinality Summary (one line per pair)
- Process ↔ Step: Process 1 — N Step
- Step ↔ Data: Step 1 — N Data
- Step ↔ Parameter: Step 1 — N Parameter (optional on Parameter)
- Parameter ↔ Data: Parameter 1 — N Data (optional on Data)
- Parameter ↔ OptionItem: Parameter 1 — N OptionItem (optional on OptionItem)
- Parameter ↔ AdvancedOptions: Parameter 1 — 1 AdvancedOptions (optional on both sides; parameterId unique)
- Parameter ↔ Parameter: self 1 — N (optional child fk) [relation: “listParameters”]
- Measurement ↔ Action 1 — N (optional) Action.measurementId is nullable
Measurement
Relationship Graph
TheMeasurement is an object of the class Process
Process is how the measurement works, the measurement holds the actual operational data.
Measurements are composed of actions.
There are 3 types of actions:
- WRITE_DATA: used when writing some data on the process.
- APPROVAL: used when a user is required to approve some WRITE_DATA action in a measurement
- REJECTION: used when a user is required to approve some WRITE_DATA action in a measurement