Managing ever-changing requirements of Request Workflow
In today’s customer-centric business landscape, a streamlined and efficient workflow with checks and balances is needed to maintain consistency, reduce errors, and improve overall efficiency. Additionally, incorporating adaptability into the system allows for a flexible approach to evolving business needs. A request workflow is a structured process that guides the progression of requests through various stages within a business. It typically involves a series of steps, approvals, and checks to ensure that requests are handled efficiently and accurately.
As a leading CRM platform, Capillary has always understood the importance of having workflows for various processes, such as changing the identifier of the customer, merging multiple customer accounts with the same identifiers, deletion of customers, issual of points and coupons to the customers, etc. As our customer base grows, we have received numerous requests from brands seeking to integrate new types of requests.
Existing Workflow
Workflows that are supported by Capillary are accessible through Capillary’s UI, allowing users to easily initiate requests, input data and track progress. Additionally, integration for workflows is also possible through APIs.
Below are the steps for the workflow process:
- User submits a request which is automatically assigned the PENDING state.
- A designated user with appropriate access reviews the request.
- A few configurations are implemented to enhance the workflow, such as sending notifications at each stage.
For example, in the identifier change workflow, a user initiates a request to modify their mobile/email identifier. An approver then reviews the request by either approving or rejecting it. Upon approval, the identifier will be successfully updated.
Problems with Existing Workflow Process
Limited Request Type Extensibility: Introducing new request types requires substantial code modifications, hindering the implementation of new features and requiring devoted time and resources from the development front for each extension.
Rigid State Management: The workflow supports only a predefined set of states (PENDING, APPROVED, REJECTED). Adding new states involves a lot of developmental changes, restricting the incorporation of additional states.
Schema changes: Our existing relational schema wasn’t generic in nature and we have separate tables for each type of request. The current schema isn’t scalable for onboarding new types of requests.
To overcome the above problems, we wanted to create a request workflow framework, that is easy to use, supports multi-tenancy and customization, is simple to onboard, etc.
New Approach
The new request framework is being developed using Camunda. The decision to adopt Camunda as our workflow orchestration engine was influenced by its demonstrated success in previous projects within our organization.
Here are some reasons for choosing Camunda as our workflow orchestration engine:
Reduced Development Time: Pre-built components such as user tasks, service tasks, and visual modeling tools streamline the development process, skip building basic workflow functionalities from scratch. This helps to integrate any new type of request with less development.
Microservices Integration: Orchestrate microservices seamlessly within the request workflows, simplifying complex architectures.
Highly flexible and customizable: Camunda’s comprehensive customization options ensure adaptability and extensibility to cater to unique business requirements.
Multi-tenancy: Camunda allows for tenant-specific customization of workflows, enabling each tenant to customize the workflow to their specific needs without the involvement of developers.
Wide range of community support: The extensive community support offered by Camunda includes access to an active user forum and comprehensive documentation. This guarantees rapid troubleshooting and efficient problem resolution.
Architecture
- The request module exposes a REST API that allows users to submit requests and receive updates on their progress.
- It is integrated with the Embedded Camunda engine that contains Process Definitions (BPMN workflows) and External Workers (Service Tasks).
- Mysql database is used to store information about the workflow, such as the status of each request and the data associated with it.
- External APIs represent integration points with external services that are part of the workflow.
Camunda provides various types of tasks to provide flexibility in modeling a wide range of business processes, combining automated and manual activities as required. Specifically, a significant emphasis is on the user tasks and service tasks in our workflow design and implementation.
User Task: Represents a task for human interaction, and its completion relies on a person to perform the required actions.
Service Task: This represents an automated task that can be implemented using various technologies or services. It does not require direct human interaction and is typically automated.
Sample workflow of a request
Start request: The process starts when a user submits any predefined type of request.
ValidateMaker Access: Camunda’s service task which validates whether the user is authorized to submit the request.
Validate Payload: Camunda’s service task that verifies if the user input is valid and moves the request to pending status.
Admin Task: Camunda’s user task which takes user input on the basis of the request.
ValidateChecker Access: Camunda’s service task which validates whether the admin who approved/rejected the request is authorized to do the same or not.
ApiTask: It calls the external API that performs the request.
In the above workflow, communication and event notifications are also sent to the clients at specific points such as when a request gets successfully initiated and ended.
Some configurations in the workflow can be customized based on the tenant such as specifying email recipients, determining whether the workflow will be auto-approved or not, and setting the maximum points to be awarded to the customer.
Drawbacks of using Camunda
- Camunda handles the data store by itself which doesn’t sit well with our ETL flows.
- Due to the lack of data sharding feature in the community edition of Camunda, scaling horizontally isn’t possible and vertical scaling is the only way to do it as of now.
Conclusion
- New workflow requirements are streamlined by using Camunda with minimal code and time investment, making the process efficient and straightforward.
- Enhancing existing workflows is simplified, as the addition of a new step to the workflow is a simple task.
