أتمتة سير العمل والموافقات
Most enterprise work gets stuck at a step 'waiting for someone's approval'. We automate task and approval flows, process design and notification chains; we free processes like document management and HR from manual tracking. This is the kitchen behind our enterprise work-management product family.
Most enterprise work gets stuck at a step 'waiting for someone's approval'
A leave request waits on a manager's desk, a contract waits for a signature, a fault sits unresolved because no one knows whose job it is. None of this is bad intent — it's just that who does what, and by when, isn't tied to a written rule, so it gets lost between people. We move that handshake into software: who approves, within how long, and who it escalates to if the deadline lapses — all defined in one engine, and when a rule changes, one place is updated.
We haven't built this engine once — it's the kitchen behind our enterprise work-management product family (work and issue tracking, document management, HR). We've run application and permit processes in our public-sector projects and the fault-request flow in our facility-management product on the same engine — the process is a configurable asset, not something buried in code.
- Who approves, within how long, who it escalates to — in one engine
- One place is updated when a rule changes
- The kitchen behind our enterprise product family
- Proven in public-sector and facility-management projects
The engine's three parts
Approval engine & state machine
The path a request follows — how many steps it passes through, which condition routes it to which role — is defined in a single state machine. When a rule changes, you edit one place, not conditions scattered across screens; the process is a configuration object, not code.
- Multi-step, conditional approval
- The process is configurable, not buried in code
- One place is updated when a rule changes
Notification chains & escalation
A reminder goes to the right person before a request's deadline lapses; if it truly lapses, the request escalates automatically to the next role up. No one says 'I forgot,' because the chance of forgetting lived in a person's memory, not in the system — we remove that risk.
- A reminder before the deadline lapses
- Automatic escalation on deadline breach
- Email, push and WhatsApp channels
Document management & HR processes
Incoming-outgoing correspondence, versioning and archiving on one side; leave, expense and hiring approval on the other — both run on the same approval engine. A leave request is submitted from a phone, lands with the manager instantly, and once approved, both the employee and HR see it at the same moment.
- Electronic document management (EDMS) and archive
- Leave, expense and hiring approval flows
- The same engine reused across different processes
The sub-services beneath the automation
An approval flow isn't a single screen; it's a chain from design to reporting.
Task & approval flow design
We design together who approves what, when, and which condition routes it to whom.
Process modeling & state machines
We define a process's steps, conditions and transitions in a configurable model.
Notification chains & reminders
A reminder before the deadline lapses, automatic escalation if it does — via email, push and WhatsApp.
Document management (EBYS) processes
Incoming-outgoing correspondence, versioning and archive; a searchable document layer with full-text search.
HR and leave/expense approval processes
Leave, expense and hiring requests run through the same approval engine; HR doesn't track them by hand.
SLA, escalation & process reports
How long a process takes and where it stalls is reported; the bottleneck rests on data, not a guess.
How we build a process automation
Process & approval mapping
We map your current process — however it lives, on paper, in email or in someone's head — and clarify its steps and rules together.
State machine & rule design
We build approval steps, conditional routing and deadline/escalation rules into a configurable model.
Notification & escalation setup
We configure reminder and escalation channels (email, push, WhatsApp) and test them with real scenarios.
Pilot & rollout
We trial with a single unit on real data rather than the whole institution at once; we see friction in the field, fix it, then roll out.
Sectors where this engine is at work
The same state machine and escalation logic runs, adapted, to a different process in each sector.
Enterprise work management
Work and issue tracking, document management and HR share the same approval engine; modules turn on one by one.
Public sector
Application and permit processes go through multi-step approval; a request past its deadline escalates automatically.
Facility management
A fault drops into the same engine: prioritized, assigned to a team, bound to an SLA, escalated if the time is breached.
Care & health
The medication administration gate is an approval step: the action doesn't complete until the right person, right time is confirmed.
What ships as standard in every automation setup
The technology we build on
- State machine
- rule engine
- push
- .NET 9
- PostgreSQL
- RabbitMQ
- Redis
Frequently asked
Do we need to write code when an approval rule changes?
No. Approval steps, conditions and deadline rules are defined in a configurable model; when a rule changes, one place is updated and screens aren't touched.
Does your document management support e-signature?
Formal e-signature integration can be added as an independent adapter; in our public-sector projects we've built systems that talk to e-signature and e-government services. We clarify the specifics together based on your needs.
Do we have to deploy everything at once?
No. You usually start with a single process (often the one that stalls most), then add HR, document management and the rest in order of need. Because they share the same engine, adding later is painless.
How does escalation work if no one notices?
A reminder goes to the right person before the deadline lapses; if it truly lapses, the request escalates automatically to the next role up. The outcome doesn't depend on anyone's memory — it depends on the system itself.
Our current processes live on paper/in Excel — how do you migrate them?
We first map your current process as it actually runs — its steps, rules and exceptions. Then we translate that into a state machine and trial it with real data in one pilot unit; we fix friction, then roll out.
Let's move your processes into automation
We'll listen to where things stall and who's waiting on whom, and map out where to start, together. The first conversation is non-binding.