Custom Approval Workflows: Fitting an Off-the-Shelf Product to Your Processes

When choosing enterprise software, you hear the same line from almost every team: “Our processes are a bit different.” Usually that’s true. The amount above which a purchase request goes to the general manager, which departments need an extra HR approval for leave, whose sign-off a document needs in which folder — all of this varies between organisations. The question is how an off-the-shelf product can accommodate those differences.

This article sets out a practical approach to custom approval workflows: use the flexibility the product already offers to the full, then close the gaps that genuinely remain with custom development or integration.

The three meanings of “our process is different”

When people say their processes are different, they usually mean one of three things. Telling them apart is the first step to the right solution:

Situation	Example	Usually the right fix
A configuration difference	How many steps the approval chain has, and who is in them	Configure it with the product’s existing settings
A habit difference	The field order or naming of a form used for years	Simplify and adapt to the product’s flow
A genuine process difference	An organisation-specific workflow the standard modules don’t cover at all	Custom development or integration

In practice, a large share of “different” needs fall into the first two groups. Solving them with custom code adds cost and maintenance for no good reason. Genuine process differences are the right candidates for custom development.

Step 1: map the current process as it really is

Before adapting anything, write down how the process actually works today — not as the procedure document says, but as it happens. For each approval flow, answer:

• Who starts the request, and with what information?
• Who approves at each step? Is that tied to a title, a department or a named person?
• Where does a rejected or returned request go?
• When does an extra approval step kick in?
• What record remains at the end, and who can see it?

This exercise is often valuable on its own: it reveals the same process run differently in two departments, approval steps that no longer add anything, and steps nobody owns.

Step 2: map the flexibility the product already offers

A good enterprise product offers some flexibility in approvals. Match your process map against the product’s options to see what configuration already covers. In HibritİK, for example, approvals are defined differently per module:

• Tasks: when a task with a manager is completed, it moves to awaiting approval; the manager approves or sends it back with a reason. If a tester is assigned, the task goes to testing and the result is recorded as Passed or Failed. Subtask approval status rolls up to the parent automatically.
• Leave requests: approval follows the managers in your department tree, with an optional HR step.
• Quality documents: revisions follow an approval chain defined per folder.
• Project and vehicle requests: follow the multi-step approval chain you define.

In every flow, each approver is notified and the approval history is kept. Pending items gather in a central approvals queue where they can be approved in bulk. See approval and test workflows for details.

Step 3: isolate the real gaps

You should end up with three lists: what the product covers directly, what a small simplification would cover, and what it genuinely can’t. For each item on the third list, ask:

1. How often does this come up? For an exception that happens a few times a year, a manual step may be enough.
2. Is it driven by a legal or audit requirement? If so, it’s high priority.
3. Does it need data from or to another system? Then it may really be an integration need.
4. Is it a new, organisation-specific process? If no standard module covers it, a custom module is on the table.

Step 4: integration or custom module?

Real gaps are usually closed one of two ways:

Integration

If part of the approval flow lives in another system — say an approved request has to reach accounting or another internal system — the answer is often an integration. HibritİK talks to your other applications through a REST API. Each integration gets its own integration account and API key, and the key works only with the permissions of the role it is given, so what the integration can reach is limited from the start. We deliver data exchange with your existing systems as an integration project planned around your needs, not as an off-the-shelf connector.

Custom module

For an organisation-specific process that no standard module covers, a custom module can be built for you. The advantage is that the new process sits inside the same product as the other modules you use, so people don’t need to look for a separate tool for it.

Running a custom development project well

Custom development usually succeeds or fails before any code is written. At HibritİK, integration and custom development projects follow three steps:

1. Define the need: together we clarify which data moves between which systems and in which direction, or which steps the new process has.
2. Set up access: where an integration is needed, an integration account and an API key with only the necessary permissions are created.
3. Build and go live: the integration or custom module is built, tested and put into use.

On your side, a few things make the project smoother:

• Name a process owner up front, with the final say on requirements.
• Keep the scope small: launch the most critical flow first, then expand.
• Involve real users in testing — they see best how the flow works in practice.
• Define the exceptions too; “what happens in this case?” is where flows are tested hardest.

Practical tip: before requesting custom development, use the product’s standard flows with your own team for a few weeks. It’s the most reliable way to separate what you truly need from what’s just habit.

Common mistakes

• Copying the old process one-to-one: assuming every paper step is still needed digitally adds needless complexity.
• A separate flow for every exception: a note or an extra step in the existing flow is often enough for rare cases.
• Giving integrations broad permissions: an integration reaching only the data it needs is a basic principle for both security and KVKK.
• Ignoring approval history: who approved what and when is the first record anyone checks in an audit or a dispute.

Conclusion: fit first, then tailor

The healthiest way to build custom approval workflows is to use the product’s built-in flexibility to the full, then close the real gaps with integration or a custom module. That keeps both cost and long-term maintenance low. For the general design principles, see our article on task approval workflows, and for the options, our integration and custom development page. To discuss a need specific to your organisation, get in touch; to try the standard flows, start your 14-day free trial.