Defining a Process Tracking System for Multi‐Step Interactions - wwestlake/Labyrinth GitHub Wiki

Defining a Process Tracking System for Multi-Step Interactions

Introduction

In software systems, a "process" refers to a sequence of steps or actions needed to achieve a specific goal. Unlike simple, one-time interactions, these processes require multiple interactions, decisions, and data points, often involving multiple users or roles. A robust system for tracking and managing these processes is essential, especially in applications where compliance, accountability, or complex workflows are involved.

This paper outlines the concept of a process, its components, and a proposed framework for tracking and controlling such processes within a database system. We will focus on the types of processes that involve more than one interaction with the system, possibly including human input at various steps, and illustrate how such processes can be modeled, stored, and managed efficiently.

What is a Process?

A process in this context is a structured series of steps or tasks that need to be executed to achieve a specific outcome. Each step may require input from different actors (e.g., users, administrators) and may involve decision points where the path of the process branches based on certain conditions or choices.

Key Characteristics of a Process:
  • Multi-step: Involves multiple actions or stages.
  • Interdependent Steps: The completion of one step may depend on the output or result of a previous step.
  • User Interaction: Some steps require input or actions from a user, administrator, or other roles.
  • Conditional Logic: The path through the process may change based on decisions, business rules, or data input.
  • Outcome-oriented: Designed to achieve a specific result or set of results.

Components of a Process

  1. Steps: Individual actions or tasks that must be completed. Each step should have:

    • A description of what needs to be done.
    • Input requirements (e.g., data needed, conditions to be met).
    • Output or result (e.g., data produced, next steps triggered).

  2. Choices: Decision points where the path of the process can change based on specific conditions or user input. Choices should be clearly defined, including:

    • Conditions that trigger each choice.
    • Possible outcomes of the decision and corresponding next steps.

  3. Business Rules: The logic that governs the choices and flow of the process. These rules ensure that the process adheres to organizational policies and procedures. Business rules should define:

    • Criteria for decisions (e.g., thresholds, permissions).
    • Actions to be taken when certain conditions are met.

  4. Actors: The users or roles responsible for executing steps or making choices within the process. This can include:

    • Initiators: Who starts the process.
    • Reviewers: Who reviews and approves certain steps.
    • Approvers: Who have the final say in decisions.
    • Performers: Who execute the steps.

Database Representation of a Process

To track and control processes, we need a way to represent them in a database. Here’s a proposed schema:

  1. Process Table:

    • ProcessId: Unique identifier for the process.
    • Name: Name of the process (e.g., "Malicious Behavior Report Handling").
    • Status: Current status of the process (e.g., "In Progress", "Completed", "Pending Review").
    • CreatedDate: Timestamp when the process was initiated.
    • ModifiedDate: Timestamp for the last update to the process.

  2. Step Table:

    • StepId: Unique identifier for each step.
    • ProcessId: Foreign key linking to the process.
    • Description: Description of the step.
    • Status: Current status of the step (e.g., "Not Started", "In Progress", "Completed").
    • AssignedTo: User or role responsible for the step.
    • OutputData: Data produced by the step, if any.

  3. Choice Table:

    • ChoiceId: Unique identifier for each choice.
    • StepId: Foreign key linking to the step.
    • Condition: The condition that triggers this choice.
    • NextStepId: The step to go to if this choice is made.

  4. Business Rule Table:

    • RuleId: Unique identifier for the business rule.
    • ProcessId: Foreign key linking to the process.
    • RuleDescription: Description of the rule.
    • Criteria: The criteria that must be met for the rule to apply.
    • Action: The action to take if the rule is triggered.

  5. Actor Table:

    • ActorId: Unique identifier for each actor.
    • Role: The role of the actor (e.g., "Admin", "User").
    • ProcessId: Foreign key linking to the process.
    • StepId: Foreign key linking to a step, if specific to a step.

Workflow Example: Handling a Malicious Behavior Report

Consider a workflow where a user reports malicious behavior. Here’s how it could be structured:

  1. Step 1: Report Submission

    • Actor: User
    • Action: Submit a report detailing the malicious behavior.
    • Outcome: Report is logged, and an initial review is triggered.

  2. Step 2: Initial Review

    • Actor: Admin
    • Action: Review the submitted report for completeness and severity.
    • Choices:
      • Approve: Proceed to a detailed investigation.
      • Reject: Send back to the user for more information.

  3. Step 3: Detailed Investigation

    • Actor: Assigned Investigator
    • Action: Perform a thorough investigation of the reported behavior.
    • Outcome: Collect evidence and compile findings.

  4. Step 4: Decision

    • Actor: Admin or Committee
    • Action: Decide on the appropriate action based on findings.
    • Choices:
      • Take Action: Apply sanctions or corrective actions.
      • Close Case: Close the report if no action is needed.

  5. Step 5: Record Actions Taken

    • Actor: Admin
    • Action: Record what actions were taken and why.
    • Outcome: Update the system with final actions and close the case.

Conclusion

Defining processes as a series of steps, choices, and business rules allows for structured and efficient management of multi-step interactions. By representing these processes in a database, organizations can track progress, ensure compliance with business rules, and maintain accountability for actions taken. This system can be adapted to various workflows, from handling user reports to complex administrative tasks, providing flexibility and control over critical processes.