PureOA turns the requests your team currently sends by message, email, or paper into forms with a defined approval path. A worker submits from their phone, it reaches the right approver, and every step is recorded.
Start with one form. Trying to model every process at once turns a focused first setup into a project nobody finishes.
Build and publish your first process
- Start from a template, or a blank draft. A template gives you a working form and path to adjust, which is usually faster than starting empty. Either way you are editing a draft — it is not visible to your team and nothing you do here affects anyone.
- Add the form fields. Ask only for what the approver needs in order to decide. Every extra field is a question your team answers forever, on a phone, and a field an approver has to read past. A leave request rarely needs more than dates, type, and a note.
- Set the approval path. Decide who approves, and in what order. Route to a role rather than to one named person wherever you can — when that person leaves or goes on holiday, a role-based path keeps working while a name-based one stalls.
- Check it while it is still a draft. SVDY validates the form and the approval path and tells you what is incomplete, before your team ever sees it.
- Publish it. Publishing is what makes the process available to submit.
- Submit a test request yourself. This is the step people skip and then regret. Submit as a real request, approve it as the approver, and follow it in the processing history until it completes. You will find the confusing field label and the missing approver here, not in a support message next week.
- Tell your team where it is. A published form nobody knows about changes nothing. One message with the name of the request and where to find it in the app is enough.
A published process cannot be edited. This is deliberate — requests already in flight must not have their rules changed underneath them. To make a change, create a new draft version, edit that, and publish it. Requests already in progress finish on the version they started on.
Design the path for the way your team actually works
Fewer approvers is better. Each additional approver is another person who has to notice, read, and act before your colleague hears back. Two steps is often the honest answer; four is usually a hierarchy being written down rather than a decision being made.
Ask what happens when the approver is away. A role-based step with more than one qualified person keeps moving. A single named approver on holiday is a request that sits for a week.
Match the form to the decision. If a field never changes the outcome, remove it.
Watch it in processing history
Every request keeps a record of where it went and who acted. That history is what you use to answer "where is my request?" without asking around, and to see which step things sit at longest. If one step is always the slow one, that is where to look — usually it is either too many approvers or an approver who is not being notified in a way they notice.
Troubleshooting
Publishing is refused because the workflow is not ready. Steps or connections are incomplete, and SVDY names what is missing. Fix it in the draft and publish again.
You are told only drafts can be edited. The process is already published. Create a new draft version and make the change there.
A submitted request reaches nobody. Check the approver step. If it routes to a role with no active person assigned, there is no one to receive it.
A request is stuck. Open its processing history to see which step it is waiting on, then follow up with that approver — or reroute it if the assignee is unavailable.
Your team is not using it. Almost always one of two things: they do not know it exists, or the form asks for more than they can answer from a phone at work. Both are cheaper to fix than they look.