A Practical Camunda Workflow Example: Internal Request Management

How to design a simple request workflow using user tasks, gateways, service tasks, notifications, and audit tracking.

After explaining what Camunda is and how it helps IT and business teams collaborate, it is useful to look at a practical example.

One of the most common use cases for workflow automation is internal request management.

In many companies, internal requests are still managed through emails, Excel files, shared folders, and manual follow-ups.

This can work for a small number of requests.

But when the volume increases, or when the process involves multiple teams, validations, deadlines, and audit requirements, manual management becomes inefficient.

This is where Camunda can bring real value.

In this article, we will design a simple internal request workflow and explain how each part of the process can be modeled in Camunda.

Why Request Management Is a Good Camunda Use Case

Internal request management is a good example because it usually combines both human actions and automated actions.

A typical request process may include:

• A user submitting a request
• A manager reviewing the request
• A team processing the request
• A system being updated
• A requester receiving notifications
• A full history being kept for audit

This type of process is easy to understand for business teams, but it also contains enough logic to show the value of workflow automation.

Camunda is useful here because it can orchestrate the full process from start to end.

It can assign tasks to the right users, apply decision rules, trigger system actions, send notifications, and keep a complete execution history.

The Business Need

Let’s imagine a company wants to automate an internal request process.

The business requirement may sound simple:

Employees should be able to submit internal requests. Depending on the request type, the request should be validated, processed by the right team, and tracked until completion.

At first, this seems straightforward.

But during the analysis phase, more questions appear:

Who can submit a request? Which information is mandatory? Which team should receive the request? Does every request need manager approval? What happens if the request is rejected? Should the requester be notified? Should another system be updated? How do we track the full history?

These questions are important because they transform a vague requirement into a clear workflow.

The Workflow Overview

A simplified version of the workflow can look like this:

Illustration of a workflow process involving business and IT teams, aligned through a shared BPMN model.

Start
  ↓
Submit Request Form
  ↓
Identify Request Type
  ↓
Requires Manager Approval?
  ├── Yes → Manager Review → Approved?
  │                         ├── Yes → Operational Processing
  │                         └── No  → Notify Rejection → End
  └── No  → Operational Processing
              ↓
          Update System
              ↓
          Notify Requester
              ↓
          End

This workflow contains the main building blocks of a Camunda process:

• Start event
• User tasks
• Exclusive gateways
• Service tasks
• Notifications
• End events

Each element has a clear purpose.

Step 1: Submit Request Form

The process starts when a user submits a request.

In Camunda, this can be represented by a start event followed by a user task or a start form.

The form should collect the required information.

For example:

Request ID
Requester Name
Request Type
Business Justification
Priority
Requested Date
Comments
Attachments

This step is important because the quality of the input will impact the quality of the workflow execution.

If the form is unclear or incomplete, the next teams may lose time asking for additional information.

A good request form should be simple, structured, and aligned with the business need.

Step 2: Identify Request Type

After submission, the workflow needs to identify the request type.

This can be done using a process variable such as:

request_type

For example:

Access Request
Control Request
Data Update Request
Exception Request
Operational Request

This variable can be used later to route the request to the right team or to apply specific business rules.

For example:

If request_type = "Access Request"
→ Send to Access Management Team
If request_type = "Control Request"
→ Send to Control Team
If request_type = "Exception Request"
→ Require Manager Approval

This is where Camunda becomes powerful.

Instead of manually deciding who should receive the request, the workflow can use clear routing rules.

Step 3: Requires Manager Approval?

Not all requests need the same validation path.

Some requests can go directly to the operational team.

Others may require manager approval before being processed.

This decision can be modeled using an exclusive gateway.

The gateway checks a condition, for example:

requires_manager_approval = true

If the value is true, the workflow goes to the manager review step.

If the value is false, the workflow skips manager approval and goes directly to operational processing.

This keeps the process flexible.

The same workflow can handle different request types without creating multiple separate processes.

Step 4: Manager Review

The manager review is a user task.

The manager can approve or reject the request.

The task form may include:

Request details
Requester information
Business justification
Manager decision
Manager comment
Approval date

The decision can be stored in a process variable:

manager_decision = "Approved"

or

manager_decision = "Rejected"

After this task, another exclusive gateway checks the decision.

If the request is approved, it continues to operational processing.

If it is rejected, the requester is notified and the process ends.

This makes the decision explicit and traceable.

Step 5: Operational Processing

Once the request is approved, or if no approval is required, the workflow moves to operational processing.

This can be another user task assigned to the right operational team.

For example:

Access Management Team
Control Team
Support Team
Data Team
Operations Team

The assignment can be dynamic.

For example:

If request_type = "Access Request"
→ candidate group = access_management_team
If request_type = "Data Update Request"
→ candidate group = data_team
If request_type = "Operational Request"
→ candidate group = operations_team

This allows the workflow to route work automatically.

The operational team receives the task, performs the action, adds comments if needed, and completes the task.

Step 6: Update System

After the operational processing, the workflow may need to update another system.

This can be modeled as a service task.

A service task can be used to:

• Call an API
• Update a database
• Create a ticket
• Generate a document
• Send data to another application
• Trigger another technical process

For example, after an access request is approved, Camunda could call an API to update an access management system.

After a data update request, Camunda could update a database or trigger a validation job.

This is where Camunda connects the business process with IT systems.

Step 7: Notify Requester

At the end of the process, the requester should be notified.

This can be done using a service task or an external notification system.

The notification may include:

Request ID
Final status
Completion date
Comment
Next steps

For example:

Your request has been processed successfully.
Request ID: REQ-2026-00125
Status: Completed

If the request is rejected, the notification should clearly explain the reason.

For example:

Your request has been rejected.
Reason: Missing business justification.
Please submit a new request with the required information.

Good notifications reduce manual follow-up and improve user experience.

Audit and Traceability

One of the strongest benefits of Camunda is traceability.

For each request, it becomes possible to know:

Who submitted the request? When was it submitted? Who approved it? Was it rejected? Who processed it? Which system action was triggered? When was the process completed? Where did the process get delayed?

This is very important in environments where control, compliance, and operational risk matter.

Instead of searching through emails and Excel files, teams can rely on the workflow history.

The process becomes auditable.

Common Design Mistakes

When designing Camunda workflows, it is important to avoid some common mistakes.

The first mistake is making the workflow too complex from the beginning.

A good approach is to start with the main process, then add exceptions progressively.

The second mistake is putting too much business logic inside scripts without clear documentation.

Business rules should be understandable and maintainable.

The third mistake is creating too many separate workflows for similar request types.

Sometimes, one flexible workflow with good routing rules is better than several duplicated processes.

The fourth mistake is ignoring error handling.

If an API call fails, the workflow should define what happens next.

Should the task be retried? Should a support team be notified? Should the process stop? Should the user receive a message?

The fifth mistake is forgetting monitoring.

A workflow is not only something that runs. It should also be monitored and improved.

Best Practices

A good Camunda workflow should be simple, readable, and aligned with the business process.

Some useful best practices are:

• Use clear task names
• Keep the BPMN model readable
• Define variables properly
• Make decision rules explicit
• Use candidate groups for task assignment
• Add timers for reminders and escalations
• Separate business logic from technical complexity when possible
• Track important decisions
• Handle technical errors properly
• Think about audit from the beginning

The goal is not only to automate.

The goal is to create a process that is reliable, understandable, maintainable, and useful for both business and IT teams.

Conclusion

Internal request management is a simple but powerful example of how Camunda can be used in real organizations.

With Camunda, a manual process based on emails and follow-ups can become a structured workflow with clear tasks, decisions, automation, notifications, and audit tracking.

Business teams gain visibility and control.

IT teams gain a clear structure for implementation and integration.

Managers gain better monitoring and reporting.

And users get a smoother request experience.

This is the real value of process automation.

In the next article, we will go deeper into the technical side and explain how Camunda can integrate with APIs, databases, and external systems to automate business processes end to end.