Workflow and Approval App Development

Approval workflows that outgrow email and spreadsheets

Every company has decisions that need a second person: a purchase over a set threshold, a discount deeper than standard, a change order on a job, a new vendor, a credit limit increase, an exception to policy. In most companies those decisions travel by email, text or a shared spreadsheet. Requesters cannot see where their request is, approvers lose it under fifty other messages, and when an auditor asks who approved a large purchase, someone searches an inbox.

Tepia builds approval apps for exactly these flows. A project manager on a construction site submits a change order with photos from a phone. A buyer requests a purchase that routes to the department head, then to the CFO because it crosses a threshold. A sales rep asks for a discount on a renewal and the sales director approves from a Teams card between meetings. Each approval then creates or updates the real record, such as a purchase order in NetSuite or a discount on a Salesforce opportunity, so nobody retypes the outcome.

The value shows up in cycle time. When requests route by rule and approvers can act from a phone, a decision that used to wait days often happens the same morning.

Common approval flows and how they route

Tepia starts by listing every approval you run today and the rule each one follows, written or not. A typical set looks like this:

Rules often turn out to be more nuanced than anyone wrote down. Discovery interviews surface the exceptions, such as capital purchases always needing the COO regardless of size, so the app matches how decisions really get made.

What goes into a dependable approval engine

The screens are simple. The engine behind them is where Tepia spends design effort, because a wrong route or a lost request erodes trust quickly.

• Configurable rules by amount, department, location, project, vendor or category, editable by an administrator rather than hard coded.
• Sequential and parallel steps, such as legal and finance reviewing a contract at the same time before the executive signs.
• Segregation of duties so nobody can approve their own request or a request they edited, which matters for SOX and internal controls.
• Rule versioning so every past decision records which version of the rule applied.
• Delegation and escalation with reminders after a set time and automatic escalation when an approver is out.
• Attachments and comments kept with the request, including supplier proposals, contracts and photos from the field.
• Single sign on through Microsoft Entra ID or Okta, so roles follow your directory. See our single sign on and identity integration page.

Tepia also builds a status view for requesters, which removes most of the follow up emails that clog approvers’ inboxes.

Built in workflow tools or a custom approval app

You may already own approval features. NetSuite has SuiteFlow, Microsoft 365 includes Power Automate approvals, and many SaaS tools have simple sign off steps. Tepia recommends using them when the approval lives inside one system, the routing is simple and a small number of people are involved.

A custom approval app makes sense when:

• One request touches several systems, such as a purchase that needs a project code from one tool and a vendor from another.
• Routing rules are complex enough that low code flows become unreadable and fragile.
• Field staff without desktop access need to submit and approve from a phone, sometimes offline.
• Auditors want one consistent trail across every type of approval.

A hybrid often works: Tepia builds the request and routing app and lets the ERP’s native workflow handle the final posting. Compare options in Power Apps vs a custom app and low code vs custom development.

How Tepia approaches workflow and approval apps

Tepia follows its six phase process, with a US based project manager accountable throughout.

1. Discovery: an inventory of current approvals and their real rules, interviews with requesters, approvers and internal audit, and a review of the ERP and CRM APIs the app will write to. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a site supervisor submitting a change order with photos.
2. Design: a routing matrix for each workflow, wireframes of the request form, the approver card and the requester status view, and the audit log format.
3. Development and Testing: an Alpha with one workflow, often purchase requisitions, and a Beta adding the rest, with test plans covering every routing branch and segregation of duties rule.
4. Training: short role based sessions for requesters, approvers and the administrator who maintains rules.
5. Launch: migration of open requests, a cutover date after which email approvals are no longer accepted, and support reps for the first weeks.
6. Support: issue resolution, bug tracking and new workflows as teams ask for them.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month. See our process or contact Tepia to map your approvals.

Frequently asked questions