What architecture to choose for a system with tasks that require multiple processing / confirmation?

Question

Database

Good afternoon!
I encountered a problem while developing the access control system server.
There are operations in the system that require a lot of checks, confirmations, etc. for their execution,
i.e. they are by nature quite long.
And in order not to freeze the user interface, I intuitively decided to try to do it this way:
- form a task,
- put it in the database,
- change the status of the task as it is completed,
- based on the results, notify the person who created this task about the results.
For example, the task of adding a new user to the system with permission to pass through the ACS.
When adding a new user by business logic
- first, the task must be formed by the HR manager
(creates a new TASK bound to the USER_ID that created the task. Status -> "New task"),
- after that, the data from the created task must be verified with the data from the remote DB.
To do this, the task in the form of a request (JSON) is passed to another module that provides this data reconciliation
(status -> "Waiting for data reconciliation").
- If the data verification is successful, the request is sent for confirmation to the system administrator
(status -> "Awaiting verification by the administrator", a new NOTIFICATION is formed containing the TASK_ID and addressed to the administrator).
- After confirmation by the administrator,
(status -> "Awaiting upload to ACS").
- And only after receiving confirmation from the ACS, you need to notify that the user has been added
(status -> "Completed", a new NOTIFICATION is formed containing the TASK_ID and addressed to the creator of this TASK, notifying of the success of the execution).
DB structure (partial):
- table TASKS(TASK_ID, DESCRIPTION(for example, in JSON format), CREATOR_ID(contains USER_ID of the person who created this task), STATUS),
- table NOTIFICATIONS(NOTIFICATION_ID, DESCRIPTION, TASK_ID(link to the task associated with to notification)),
- table USER_NOTIFICATION(USER_ID, NOTIFICATION_ID) - many-to-many relationship,
because a notification can be addressed to many users and one user can have many notifications.
Creating a task consists of adding an entry to the TASKS table.
Notifications are sent by creating a notification in the NOTIFICATIONS table and adding an entry to the USER_NOTIFICATION table
to understand who the notification is addressed to.
As I understand it, for such behavior of the system there must be some design patterns.
Can you please tell me which ones, if any?
Perhaps I chose the wrong path and I need to implement something like this in a different way.
Tell me, please, in which direction to look, what to read.

Answer 1

State Machine
Shows itself well in various kinds of CRM, call centers, Order Proceesing in complex systems.
From one state, you can only go to certain ones, each state is valid, only certain transitions are open, and in general, this design approach helps to deal with the complexity of conditions and state control .

Circuit example 1

Circuit example 2