Design Guideline Discussion

Knowledge Base
1

Discussion on design guidelines.

2

When configuring a workspace:

  • Minimize the use of State and Activity wherever possible.

Quick Setup Guide:

Step 1: Define the State
Step 2: Create the Activity
Step 3: Create Information field
Step 4: Set up Automation
Step 5: Configure Authorization and Listing

This approach simplifies how to gather requirements from the customer and helps lay a strong foundation for configuring the workspace.

3
  • The State is used to control the Activity in a module.
  • All State should be changed through Activity.
  • Most of the time, the State were named with Adjective, the Activity were named with Verb, and the Information were named with Nouns.

Guidelines when analysing the requirement:

  1. Pinpoint the State needed
  2. Identify/Define the Activity to link the State
  3. Identify the information needed in each Activity (Remarks: Should know where the information comes from, and what information is needed to generate during the Activity)
  4. (optional) Set up Automation to link the module/ to automate the process.
  5. Configure Listing, set up Authorization
  6. (optional) Configure Template (document template or report template).
4

When building a system in Inistate, development should always begin with basic logic.
At its core, every system revolves around the state of an entry (or item).

Imagine it like planning a train journey:
Each train station represents a state, and the train tracks are the activities—the actions that move an item from one state to another.

1. Start with Basic Logic – Identify the States (Train Stations)

Just like a railway line must know which stations the train will stop at, your system must first define its states.

Each state should answer:

  • Where is the item in its process?
  • Who is responsible at this stage?
  • What can or should happen next?

Tip: Use adjectives to name states (e.g., Pending, Approved, Rejected).

2. Define Activities – Connect the States (Train Tracks)

Next, determine how an item moves from one state to another. These are your activities.

Think of each activity as sending the train to the next station.

Tip: Use verbs for activity names (e.g., Submit, Approve, Reject).

3. Determine the Required Information (The Tickets)

Before a train departs, passengers need tickets. Similarly, before an activity can proceed, certain information must be collected.

For each activity, define:

  • What data the user needs to provide.
  • Any validation rules required to proceed.

Tip: Use nouns for field names (e.g., Date, Amount, Remarks).

4. Define the Happy Flow – The Ideal Train Route

The happy flow is the ideal journey your item should take—smooth and uninterrupted from start to finish.

Design this first to ensure the system’s core functionality is clear and efficient.

Tip: Keep the number of states and activities to a minimum. Simplicity is key for maintainability and user experience.

5. Build Other Modules with the Same Logic

Each module is like a different train line—but they all follow the same concept:

  • States = Stations
  • Activities = Tracks
  • Fields = Tickets

Repeat the same steps:
Define states → Set activities → Identify required fields → Map out the happy flow.

6. :gear: Use Automation to Link Modules (Multi-Line Coordination)

Sometimes, a train in Line A should only move when a train in Line B reaches a specific station. This is where automation comes into play.

Rule: Only introduce automation after each module works properly on its own.

Example:
When Module B reaches the state Completed, trigger an activity in Module A to change its state to Ready.

7. Set Authorization – Access Control

Once your system runs smoothly, define who can:

  • View specific information.
  • Perform specific activities.
5

Guideline when do configuration in the workspace:

  1. Define State
  • minimize the number of state used and in simple word (max 10)
  • use to summarize the job state and control activity
  • suggestion - state in adjective
  1. Activity
  • thinking about what message that person will receive
  • use to link the state
  • allow update information without affecting other data
  • suggestion - activity in verb
  1. Information in Activity
  • think about what information is needed in the activity and extract important information
  • confirm and create the flow
  1. Automation
  • replace manual work
  1. Listing and Authorization
  • extract key information for better clarity
  • set permission to access
6

There are potential risks involved when modifying items within the Inistate. Changes to one component may affect others that depend on it. Understanding these dependencies prevent unintended errors or disruptions in configuration.

Dependency Map (Inistate)

  • INFORMATION → used by Activity, Flow, Listing, Document
  • STATE → used by Flow, Listing
  • ACTIVITY → depends on Information; used by Flow
  • FLOW → depends on State, Activity, Information; used by Listing
  • LISTING → depends on State, Information
  • DOCUMENT → depends on Information
  • LOGIC

Cross-Cutting feature:

  • Authorization
  • Notification
  • Integration
  • Automation

Insights from dependency map

  1. Modifying/deleting core components(e.g., Information, Activity, State) can break dependent items like Flows, Listings, or Documents — review dependencies first.
  2. Adding new components (e.g., Information fields, Activities, States) is generally safe.
  3. Modifying Documents poses low risk, but removing Information fields may affect them.
  4. State is independent but widely used — deleting/renaming it can have broad impacts.

The ideal scenario is that the user provides their requirements to GPT, which then generates a YAML schema. The user can simply copy the schema and paste it into Inistate to build their system. The YAML schema is simple and easy to understand for both IT and non-IT professionals.

7

Dependency

  1. Information → Database
  2. Activity → Information, method
  3. Flow → State, Activity, Information(with condition)
  4. Listing → Information, State
  5. Document → Information

No Dependency (safe when change)

  1. Information
  2. State
  3. Authorization
  4. Document
  5. Notification

Cross-cutting (related to all dependency)

  1. Authorization
  2. Document
  3. Notification
  4. Integration
  5. Automation

YAML Schema

  1. Use GPT to generate schema
  2. Can chat with GPT about the requirements and ask GPT to generate (as consultation)
  3. Generate template in Inistate based on schema

Benefit of schema

  1. Easier to understand and configure
  2. Save time
8

At the top of the Inistate hierarchy are Information and State, which are foundational and independent of other features.

  • Information: Utilized by Activities, Flows, Listings, and Documents.
  • State: Used by Flows and Listings.

Feature Dependencies:

  • Activity: Depends on Information; used within Flows.
  • Flow: Depends on State, Activity, and Information.
  • Listing: Based on State and Information.
  • Document: Generated based on Information input.

Cross-Cutting Features:

  • Authorization
  • Document Generation
  • Notifications
  • Automation

Activity Influences:

  • Activities can be influenced by:
    • Automation (external triggers)
    • Integration (internal logic or systems)
9

Regarding YAML Schema:

  • Subject to generate by GPT after user provides the requirements to GPT.
  • Simplier than json format and more easier to understand by people even IT and non-IT professionals.

Regarding Dependency:

  1. Information (represents Database)
  2. Activity (represents Method in programming language) → depends on Information
  3. State
  4. Flow → depends on State and Activity, sometimes depends on Information too
  5. Listing → depends on State or Information
  6. Document → depends on Information
  7. Logic*

Cross-cutting dependancy:

  1. Authorization
  2. Notification
  3. Document
  4. Integration (external linking via API)
  5. Automation (internal linking within workspace)

Safe action within module (low risk)

  • create new Information, Activity, State, Listing
  • set Authorization
  • create/modify Document

Not safe action within module (high risk)

  • modify/delete Information, Activity, State
    • will impact other items which depends on it