Stateflows

In kis.ai, we introduce a powerful feature called stateflows, which function similarly to state machines. Stateflows are assigned to fields within an application, defining the finite set of values a field can hold and the specific order in which these values can be transitioned.

Key Features of Stateflows:

Finite State Management: Stateflows allow developers to define a finite set of permissible values for a field. This ensures that fields can only take on values that are pre-defined, maintaining data integrity and consistency.
Controlled Transitions: Stateflows specify the order of transitions between states. This means that a field can only change its value in a manner that follows the pre-defined stateflow, preventing invalid state changes and ensuring logical consistency within the application.
Validation and Enforcement: By using stateflows, kis.ai enforces validation rules directly within the application’s data model. This reduces the need for additional validation logic in the application code, simplifying development and maintenance.
Workflow Automation: Stateflows automate workflows by dictating the sequence of states a field can traverse. This is particularly useful for business processes that require fields to follow a specific progression, such as order statuses, approval processes, or lifecycle stages.
Error Reduction: The structured nature of stateflows helps in reducing errors that can arise from manual state management. Developers can rely on the defined stateflow to handle state transitions correctly, leading to fewer bugs and more predictable application behavior.

Example: Bug with a Stateflow

Consider a ticketing system where a ticket can be in one of the following states: “Open,” “In Progress,” “Resolved,” and “Closed.” The stateflow for the ticket status field might be defined as follows:

Ticket & Ticketflow

1
entities:
2
- name: ticket
3
  inherits: kisai.id
4
  fields:
5
  - name: name
6
    type: string
7
    validations:
8
      - type: required
9
  - name: description
10
    type: string
11
  - name: duedate
12
    type: date
13
  - name: priority
14
    type: taskpriority
15
  - name: assignedto
16
    type: string
17
  - name: state
18
    type: string
19
    stateflow: ticketflow
20
stateflows:
21
- name: ticketflow
22
  initial: Open
23
  states:
24
  - name: Open
25
    on:
26
      START:
27
        target: accepted
28
  - name: In Progress
29
    on:
30
      RESOLVE:
31
        target: Resolved
32
  - name: Resolved
33
    on:
34
      CLOSE:
35
        target: Closed
36
      REOPEN:
37
        target: Open
38
  - name: Closed
39
    type: final

Each transition from one state to another is controlled and validated by the stateflow, ensuring that a ticket cannot be moved directly from “Open” to “Resolved” without first being “In Progress.”

In this example, the state field can only transition between states in the order specified. Attempting to set the field to a state outside this order would result in a validation error, enforcing the logical flow of the ticket lifecycle.