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:
Requester Role:
Can initiate actions or requests.
Submits necessary information for the requested action.
Limited permissions, primarily focused on initiating requests.
Approver Role:
Reviews and approves/rejects requested actions.
Has broader permissions to manage approvals.
Workflow:
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.
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.
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.
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.
Status Updates:
The system updates the status of the request to reflect whether it was approved, rejected, or is still pending.
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 Workspace - openTasks section. Only this user will see the creation of the task.Assignee Role:
Only users with the selected role will be assigned to choose a solution for a task in the Workspace - openTasks section.Assignee Permission:
Only users with selected access will be assigned to select a solution for a task in the Workspace -openTasks section.Params Key:
Specify the key in which the data will be displayed when selecting a decision for the open task. By default, it is initialDataOutport N:
A solution to the given task that will progress 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 serves as the departure point for the request to move to the next connected node or exit. Multiple ports may exist, depending on the options created for problem resolution.
actionCall [Call any action of any service]
...
Action: A functionality accessible within the GraphQL endpoint of the project, which can be invoked with the provided parameters.
Params Key: The key containing the data passed to the function call. Default is initialData.
Result Key: A key containing data from the function — standard result.
In: Connects the previous node and transfers data.
Success: Connects to the next node upon successful execution of the function.
Error: Connects to the next node when execution fails.
CheckPermissions [Check permissions]
...
Params Key: Specifies the key containing the employee's permissions whose access needs to be checked. The default is initialMeta.permissions
Permissions: Selection of permissions that will determine the transition to the true port.
In: Connects the previous node and transfers data.
True: Connects to the next node if the selected accesses match the selected employee's access.
False: Connects to the next node if the selected accesses do not match the selected employee's access.
checkRoles [Check roles]
...
Params Key: Specifies the key containing the ID of the employee whose roles need to be checked. The default is initialMeta.user.id
Roles: The selection of roles will determine the transition to the true port.
In: Connects the previous node and transfers data.
True: Connects to the next node if the selected roles match the role of the selected user.
False: Connects to the next node if the selected roles do not match the selected user's role.
copy [Copy data]
...
From: The key containing the data to be copied.
To: The key where the data to be copied will be located.
+Add Copy action: Creates additional keys whose data will be copied to other keys.
In: Connects the previous node and transfers data.
Out: Connects to the next node and transmits data.
delete [Delete values]
...
Delete Item: A key with a value that will be deleted and passed on without this data.
Add Delete action: Adds fields where the key for deleting data will be specified.
In: Connects the previous node and transfers data.
Out: Connects to the next node and transmits data.
if [If condition]
...
Condition: Description of the condition under which the connection of the next node will be directed through the true output. For example, wallets.length > 0.
In: Connects the previous node and transfers data.
True: Connects to the next node and transfers data when the specified condition is met.
False: Connects to the next node and transfers data if the specified condition is not fulfilled.
set [Set values]
...
Key: The identifier where the transferred data in the Value field will be stored.
Type: The data type to be saved:
String
Number
Boolean
Expression
When selecting ‘Expression’, - concatenate strings with values to return a string type. For example, "Create a new currency: " + initialData.id, where initialData.id represents the ID of the new currency. The resulting value might be, for instance, "Create a new currency: USDT".
Value: The data to be saved.
Add Set action: Adds another block for setting data.
In: Connects the previous node and transfers data.
Out: Connects to the next node and transmits data.
startNode [Starting point of any workflow]
Out: Establishes the connection to the next node and facilitates the transfer of data.
endNode [End point of workflow]
In: Connects the previous node and completes the Workflow execution.
New workflow creation
In this guide, we'll explore the process of constructing a workflow system that incorporates both requester and approver employees, task creation, decision-making, and seamless workflow operation without requiring approval configuration from a super-admin. Additionally, we'll delve into the management of permissions for employee roles, auditing logs, and tracking runtimes during and after the approver's decision.
To manage workflows effectively, an employee needs permission to editWorkflow and viewWorkflows for their role, including the ability to edit workflows and view existing workflows.
...
The next step is to assign the appropriate role to the employee.
...
So, now an employee with the email qa@tunex.io has the role ‘superadmin’ with permissions ‘editWorkflow’ and ‘viewWorkflows’
Login to Puppeteer with the credentials qa@tunex.io and navigate to the Configurations page. Once there, locate the "Workflows" sub-menu. Click on it to access the workflows section. Now, press the "+" button to initiate the creation of a new workflow. Let's embark on the journey of creating a process specifically designed for updating existing Currency configurations.
...
Give the workflow a unique name such as "updateCurrency." Next, select the initial component that should be used in the workflow.
After successfully creating the workflow, there will automatically be a start node and an end node.
...
In the following workflow, the first step is to check employee permissions. To determine the possibility of editing currency configurations or making requests for edits, the employee's role should have permission to viewCurrencies and editCurrency. Therefore, it makes sense to add a 'check permission' node where these permissions are verified. In the event that the employee lacks such permissions, the workflow will proceed to the 'end' node.
...
If the workflow is simple enough and there is no need to check anything else except permissions, the next step is to add an action call that launches the expected result.
...
The audit logs for such workflow will be the following:
...
| Expand | ||
|---|---|---|
| ||
|
| Expand | ||
|---|---|---|
| ||
|
The runtimes for such workflow will be the following:
...
| Expand | ||
|---|---|---|
| ||
|
There is the possibility to add a Role check node. If an employee has permission to update currency but their role is unexpected for such a workflow, it would end the workflow. However, if the role of the employee is correct, the workflow will proceed with an Action call to currencies.updateCurrency.
...
Login to Puppeteer with the credentials businessanalyst@marionette.dev and navigate to the Configurations page. Once there, locate the "Currencies" sub-menu.
For example, if an employee does not have the 'superadmin' role (as indicated by the role check node), they attempt to update currency user balance enabled, hidden, and trading commission enabled.
The audit logs for such workflow will be the following:
...
| Expand | ||
|---|---|---|
| ||
|
The runtimes for such workflow will be the following:
...
| Expand | ||
|---|---|---|
| ||
|
As we can see, if an employee does not have the role that is being checked in the workflow, then the workflow will end without any action calls.
In this part of Workflow creation, we will review the model with the Requester who makes a request to update currency, and the Approver who will review the request and make a decision. For this flow, there should be a connection between the Requester and Approver employees through task creation in Workspace mode.
Therefore, both the Requester and the Approver should be granted the permission "useWorkspace" and "manageTasks".
This allows the Requester to observe the status of created tasks.
Additionally, the Approver requires additional permission, "acceptCurrency", which enables one to view task details and make decisions. Without this permission, there is no option to review task details and make a decision.
In this example, employee businessanalyst@marionette.dev will act as the Requester, while employee qa@tunex.io will serve as the Approver.
To enable task creation for the Requester and decision-making for the Approver, the workflow model should include "set" and "user decision" nodes.
...
After the "set" node, there will be a "user decision" node with the following main conditions:
Component: Within the framework of workflow construction, the “user decision” element plays a crucial role, allowing the administrator to decide whether to confirm or cancel changes to the data. This element includes a Component attribute, used to visually represent changes to the administrator. Visual representation may include added, modified, created, or deleted data. The Params Key attribute is utilized to pass this data to the Component, enabling the administrator to visually evaluate changes before approving or rejecting them.
Assignee User: The Approver can be assigned by email.
Assignee Role: The Approver can be assigned by role.
Assignee Permission: The Approver can be assigned by permission.
Out port "Approve": This port has a primary color for the button in task details (positive).
Out port "Reject": This port has a danger color for the button in task details (negative).
As observed in this flow, if the Approver makes an "Approve" decision, the next step will be an "action call" with currencies.updateCurrency. Conversely, if the decision is "Reject", the workflow will proceed to the "end" node.
Workflow Process for updating Currency configurations
Steps for Requester. Login to Puppeteer with the credentials businessanalyst@marionette.dev and navigate to the Configurations page. Once there, locate the "Currencies" sub-menu.
Initiating a creation request with updating currency configurations for the "platform payout fee".
...
The requester can view their created open task in the Workspace and monitor its status.
...
Steps for Approver
Reviewing the request: The approver can observe the new task created by the requester and its details. The fields that are requested to be changed are marked with a different background color.
...
If the Approver decides to reject the request, it will be declined without any changes to the Currency configuration. The task status will be set to 'resolved', and it will be removed from the open tasks list for both the Approver and the Requester in the Workspace.
...
| Expand | ||
|---|---|---|
| ||
|
| Expand | ||
|---|---|---|
| ||
|
Troubleshooting
Common Issues and Solutions
Error Messages and Their Meanings
Glossary
Definitions of Key Terms Used in the Documentation
Appendix
Additional Resources
Contact Information for Support
...