Creating a workflow for an admin panel with distinct roles for requesting and approving actions involves defining a series of steps and permissions. Below is a basic outline of the workflow, along with the roles and their respective responsibilities. Keep in mind that the actual implementation may vary depending on your specific requirements and the technology stack you are using.

Roles:

1. Requester Role:

   • Can initiate actions or requests.

   • Submits necessary information for the requested action.

   • Limited permissions, primarily focused on initiating requests.

2. Approver Role:

   • Reviews and approves/rejects requested actions.

   • Has broader permissions to manage approvals.

Workflow:

1. Request Initiation:

   • The Requester logs into the admin panel.

   • Navigate to the section for initiating actions or requests.

   • Fills out a request form, providing all necessary details.

   • Submit the request.

2. Request Review:

   • The system logs the request and notifies the Approver role.

   • The Approver logs into the admin panel.

   • Navigate to the pending requests section.

   • Review the details of the request.

3. Approval Process:

   • The Approver has the option to approve or reject the request.

   • If approved, the system proceeds with the requested action.

   • If rejected, the system notifies the Requester with a reason for rejection.

4. Action Execution:

   • If the request is approved, the system executes the requested action.

   • This may involve database updates, changes in configurations, or other relevant operations.

5. Status Updates:

   • The system updates the status of the request to reflect whether it was approved, rejected, or is still pending.

6. Notification:

   • Both the Requester and Approver receive notifications on the status of the request.

   • Notifications may be in-app alerts, emails, or any other preferred communication method.

Additional Considerations:

• Logging and Auditing:

  • Maintain detailed logs of all actions, including who initiated requests and who approved them.

  • This helps with accountability and auditing.

• Role-Based Access Control (RBAC):

  • Ensure that permissions are well-defined for each role to prevent unauthorized access.

• User Interface:

  • Design a user-friendly interface that indicates the status of requests and provides necessary information for both roles.

• Security:

  • Implement proper security measures to protect sensitive data and actions.

• Scalability:

  • Design the system to scale as the number of requests and users increases.

• Customization:

  • Allow for customization of approval workflows based on specific business needs.

Customize this basic outline according to your specific requirements, and consider involving stakeholders and end-users in the design process to ensure the workflow meets their needs effectively.

Workflow nodes

New Workflow:

...

• Edit name for Workflow

• Workflow JSON : …..

• Select ‘Workflow Initial Component’ : ….

• + Add param
  - Key:
  - Data type:

• 'Enabled' toggle
  

1. userDecision [Flexible user decision]

...

• Component: Web Component Selection

  Assignee User:
  Selection of the person to whom the task will be assigned by choosing a task solution in the Workflow -> openTasks section. Only this user will see the creation of the task. You can choose only one: Assignee User | Assignee Role | Assignee Permission

  Assignee Role:
  Only users with the selected role will be assigned to choose a solution for a task in the Workflow -> openTasks section. You can choose only one: Assignee User | Assignee Role | Assignee Permission

  Assignee Permission:
  Only users with selected access will be assigned to select a solution for a task in the Workflow -> openTasks section. You can choose only one: Assignee User | Assignee Role | Assignee Permission

  Params Key:
  Specify the key in which the data will be displayed when choosing a solution to the problem. By default, it is initialData

  Out port N:
  An option for solving the given problem that will lead to the next node in the chain

  • Name: The name of the solution

  • Primary: The button will be painted in the basic color of the platform (oriented towards a positive decision)

  • Danger: The button will be painted in red (oriented towards request rejection)

  +Add Out Port:
  Adding additional options for solving the problem
  

  In: This signifies the connection of the previous node and the transfer of data regarding the task.
  

  Out Port: This port is where the request will depart to the next connected node or exit. Multiple ports may exist, depending on the created options for problem resolution.

...

In: Connects the previous node and completes the Workflow execution.

Workflows

1. Admin Deposit

Conditions for nodes:

...

2. Admin Withdraw
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

3. Turn off user 2 FA
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

4. User soft ban
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

5. Create / Update Currency
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

6. Create / Update Market
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

7. User KYC
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

8. Operations with error / Cancel order
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

9. Create / Update referrals groups
   Conditions for nodes:

   Conditions for permissions:
   Requester Role:
   Approver Role:

   Audit logs:
   

10. Blockchains configuration
    Conditions for nodes:

    Conditions for permissions:
    Requester Role:
    Approver Role:

    Audit logs:
    

11. Create / Update Workflow
    Conditions for nodes:

    Conditions for permissions:
    Requester Role:
    Approver Role:

    Audit logs:
    

12. Create / Update Manual rates
    Conditions for nodes:

    Conditions for permissions:
    Requester Role:
    Approver Role:

    Audit logs:
    

13. Create / Update roles
    Conditions for nodes:

    Conditions for permissions:
    Requester Role:
    Approver Role:

    Audit logs:
    

14. Create / Update Privileged Users
    Conditions for nodes:

    Conditions for permissions:
    Requester Role:
    Approver Role:

    Audit logs:
    

15. Soft ban / Soft unban all users
    Conditions for nodes:

    Conditions for permissions:
    Requester Role:
    Approver Role:

    Audit logs:
    
    
    _______________________________________

Workflow Overview

1. Description of Workflow Process

2. Roles Involved in Workflow

3. Workflow Diagram

Creation Process

1. Steps for Requester

   • Initiating a Creation Request

   • Providing Necessary Information

2. Steps for Approver

   • Reviewing the Request

   • Approving or Rejecting the Request

Update Configurations

1. Steps for Requester

   • Initiating an Update Request

   • Providing Details of Configuration Changes

2. Steps for Approver

   • Reviewing the Update Request

   • Approving or Rejecting the Changes

Operations Approval

1. Steps for Requester

   • Requesting Approval for Operations

   • Providing Context and Details

2. Steps for Approver

   • Reviewing the Operation Request

   • Approving or Rejecting the Operation

Best Practices

1. Tips for Effective Request Submission

2. Guidelines for Approvers

Troubleshooting

1. Common Issues and Solutions

2. Error Messages and Their Meanings

Glossary

1. Definitions of Key Terms Used in the Documentation

Appendix

1. Additional Resources

2. Contact Information for Support