Skip to content

Use Cases for AI-Enhanced Workflow

Use Case 1: Admin User Management (with Confirmation)

  • Actor: System Administrator
  • Scenario: An admin needs to quickly add a user to a specific group.
  • Steps:
    1. Admin opens the chat interface.
    2. Admin types: /group addUserToGroup --user "jdoe" --group "auditors"
    3. The system validates the admin's permissions and presents a plan: "I am about to perform the following action: Add user 'jdoe' to group 'auditors'. Please confirm to proceed." The message includes [Confirm] and [Cancel] buttons.
    4. Path A (Confirmation): a. Admin clicks [Confirm]. b. The system executes the action. c. The chat returns a confirmation: "Success: User 'jdoe' has been added to the 'auditors' group." d. The confirmed action is recorded in the audit trail.
    5. Path B (Cancellation): a. Admin clicks [Cancel]. b. The system aborts the action. c. The chat returns a message: "Operation canceled." d. The canceled action is recorded in the audit trail.

Use Case 2: Information Query by a Standard User

  • Actor: Standard User
  • Scenario: A user wants to find documentation about resetting their password. (This is a read-only operation and does not require confirmation).
  • Steps:
    1. User opens the chat interface.
    2. User types: "how do I reset my password?" or /knowledge search "password reset"
    3. The system identifies the intent as a knowledge base query.
    4. The system searches the knowledge base and returns the relevant article or a summary directly.

Use Case 3: Unauthorized Action Attempt

  • Actor: Standard User
  • Scenario: A standard user attempts to perform an administrative action.
  • Steps:
    1. User opens the chat interface.
    2. User types: "add jane.doe to the administrators group"
    3. The system identifies the intent and checks the user's permissions before forming a plan.
    4. The system denies the request.
    5. The chat returns a message: "Error: You do not have permission to modify user groups."
    6. The failed attempt is recorded in the audit trail.

Use Case 4: Chat History Retrieval and Continuation

  • Actor: Any authenticated user
  • Scenario: A user wants to find a conversation from last week about user permissions.
  • Path A (Via UI Button):
    1. User clicks the "Chat History" button in the UI.
    2. A list of previous chat sessions is displayed (e.g., with timestamps and the first message as a title), sorted with the newest first.
    3. User selects the relevant session.
    4. The chat interface loads the selected history, and the user can continue the conversation from where they left off.
  • Path B (Via @ Command with Auto-complete):
    1. User types @ in the chat input.
    2. The UI immediately displays a list of recent chat sessions, sorted with the newest at the top.
    3. As the user types further (e.g., @user-perm), the list filters to match the input.
    4. User selects the desired session from the list (e.g., @user-permissions-chat).
    5. The chat interface loads the selected history, and the user can continue the conversation.

Use Case 5: Multi-Step Command Orchestration

  • Actor: System Administrator
  • Scenario: An admin needs to create a new user and immediately add them to a group.
  • Steps:
    1. Admin opens the chat interface.
    2. Admin types: "Create a new user 'testuser' with email 'test@example.com' and add them to the 'readers' group."
    3. The system validates the admin's permissions and presents a multi-step plan: "I am about to perform the following actions: 1. Create user 'testuser' with the email 'test@example.com'. 2. Add user 'testuser' to group 'readers'. Please confirm to proceed."
    4. Admin clicks [Confirm].
    5. The system executes both actions in sequence.
    6. The chat returns a final summary: "Success: User 'testuser' has been created and added to the 'readers' group."

Use Case 6: Post-Confirmation Execution Failure

  • Actor: System Administrator
  • Scenario: An admin attempts to add a user to a group that does not exist.
  • Steps:
    1. Admin opens the chat interface.
    2. Admin types: add jdoe to group "nonexistent_group"
    3. The system presents the plan: "I am about to perform the following action: Add user 'jdoe' to group 'nonexistent_group'. Please confirm to proceed."
    4. Admin clicks [Confirm].
    5. The mcp_service attempts to execute the action but the underlying API returns an error.
    6. The chat returns a user-friendly error message: "Error: The action could not be completed because the group 'nonexistent_group' does not exist."
    7. The failed action is recorded in the audit trail.

Use Case 7: Data-Filtered Information Query

  • Actor: Department Manager
  • Scenario: A manager wants to see a list of users within their own department only.
  • Steps:
    1. Manager opens the chat interface.
    2. Manager types: "show me all users in my department"
    3. The system identifies the intent and the user's identity and role (Manager of 'Sales' department).
    4. The system queries the user service, but includes a filter based on the user's permissions.
    5. The chat returns a list of users that only belong to the 'Sales' department, respecting the user's data access rights.