Build the workflow before you automate the tool. Automation creates value when it makes real work easier to run, easier to see and easier to control — and the opportunity is usually sitting inside the workflows people already fight with every day.
Approvals stuck in inboxes, spreadsheets as control towers, duplicate entry, unclear handoffs, manual reporting. Inlight IT turns broken or manual workflows into structured applications and automations people actually use — Power Apps, Power Automate, Dataverse and custom builds — so the work moves faster, stays visible and gets simpler to improve over time.
- Workflow first, tool second
- Power Platform or custom, chosen to fit
- Built to be supportable, not orphaned
Automation opportunities usually start with friction people already know about.
Most automation projects do not begin with a transformation plan. They start because a team is tired of a process that should be easier. A manager cannot see where approvals are stuck. A finance team is rekeying the same information into several places. A job-tracking process is buried in spreadsheets. A manufacturing workflow runs on email, memory and manual updates. These are not just administration problems. They are visibility, control and decision problems, and that is exactly where automation pays off.
People know what needs to happen, but the workflow runs on inboxes, spreadsheets and memory, and no one can see where it is stuck.
The automation question starts with workflow, then becomes a platform decision.
The process exists, but it is held together manually
People know what needs to happen, but the workflow runs on email chains, spreadsheets, shared folders, Teams messages and follow-up calls.
Approvals are slow because ownership is unclear
Requests move from person to person without a reliable way to see who owns the next action, what is waiting, what has been rejected, and where exceptions are building up.
Data is captured, but not in a useful structure
The business has forms, spreadsheets or documents, but the information is hard to validate, hard to reuse and hard to report on.
Reporting is harder than it should be
Leaders want visibility across requests, jobs, production, approvals, turnaround time or backlog, but the workflow was never designed to produce that information.
The team wants an app, and the real win is the operating model
A Power App or custom application helps most when the process, owner, rules, data, exceptions and support model are clear enough to build around.
The first platform suggestion may not be the right one
Power Platform is excellent for many internal workflows. Custom development is better where the process is highly specific, long-lived, operationally important, or needs ownership without vendor lock-in.
We turn manual workflows into structured applications and automations.
Good automation starts with the workflow, not the software.
1Find the workflow worth automating
Processes that happen often enough to matter, are painful enough to justify change, have a clear owner, produce measurable outcomes, and can be standardised without the exceptions swallowing the rule.
2Map the current process
Who starts it, who approves it, what data is captured, where the handoffs and exceptions are, what reporting is needed, and which systems the workflow already touches.
3Choose the right build path
Power Platform where the process fits Power Apps, Power Automate and Dataverse. Microsoft 365 workflows where a lighter approach is enough. Custom applications where the process is too specific or too strategic to force into a low-code pattern.
4Design the data model
Automation only works when the data has structure. We define fields, relationships, status logic, permissions, validation and reporting outputs before the build becomes hard to control.
5Build the workflow, not just the screen
Forms matter, but the value is in the workflow behind them: routing, approvals, notifications, exception handling, audit trail, reporting and supportability.
6Make the result supportable
Ownership, documentation, access control, change management and a clear support model are part of delivery, so the work compounds instead of becoming another orphaned application.
Power Platform where it fits. Custom applications where the process needs more.
Automation should not be reduced to one tool, and we bring the right one to the workflow.
Power Apps, Power Automate and Dataverse work well for request workflows, approvals, structured data capture, inspection forms, internal applications, workflow dashboards and moderate-complexity business processes inside Microsoft 365.
Manufacturing, job control, production planning, quotation logic, operational coordination and long-lived business-specific applications often need a custom build with stronger ownership and fewer platform constraints.
If an established product fits, the business should not build unnecessarily. The call is made on fit, ownership, cost, supportability and how specific the process really is.
The decision matters before the build starts. The wrong platform makes the first version look fast and the second version expensive. The right architecture is the one the workflow can live with for years.
A defined path from workflow to supported application.
Current process, users, triggers, data, approvals, exceptions, reporting needs and systems involved.
Some workflows need standardising before automation. Some need a Power App. Some need a custom application. Some are better served by a SaaS product or a lighter Microsoft 365 workflow.
A clear scope: the workflow, user groups, data model, approval rules, reporting output and support responsibilities.
Power Apps, Dataverse, SharePoint, SQL, open-source foundations or custom architecture, selected to fit the workflow rather than the reverse.
Tested against real users, real exceptions and real reporting needs. The goal is a workflow the business can rely on, not just a working screen.
Documentation, access control, ownership, change process and support model, so automation removes friction instead of adding an unsupported estate.
A workflow that is easier to run and easier to see.
Information is captured with structure. Approvals have clear ownership. Status is visible. Exceptions are easier to manage. Reporting improves because the workflow now produces usable data. People spend less time chasing, rekeying and reconciling.
Forms, fields and data models that validate on entry and stay reusable downstream.
Every request has a visible owner for the next action, with exceptions surfaced rather than buried.
The business can see where work is, what is waiting, and where the bottlenecks are building up.
Once the workflow moves out of inboxes and spreadsheets, it produces usable data on volume, turnaround and ownership.
People spend their time on the work itself instead of holding the process together by hand.
Some workflows continue through Power Platform, some justify custom applications, some are better solved by SaaS, and the choice is made deliberately, with the process, data, ownership and support model understood before the build scales.
Automation sits between process, application design, data, identity, security and support.
That makes it work for an engineering-led MSP rather than a pure app shop or a citizen-development model. We understand the systems these workflows live inside: Microsoft 365, identity, permissions, devices, cloud, databases, backup, security and managed operations. A workflow application rarely lives alone; it sits inside the environment people already rely on, and that is where we are strong.
01Engineering-led, not a pure app shop
We bring the whole picture rather than treating the app as an isolated screen: process, data, identity, security and support around it.
02We understand the environment the workflow lives in
Microsoft 365, identity, permissions, devices, cloud, databases, backup, security and managed operations. A workflow application sits inside the systems people already rely on.
03Proof across both sides of the decision
Power Apps for Beijer, custom application development for HBT Waratah Engineering, and three custom applications for Questas built around how the operation actually works.
04The right platform follows the workflow
That breadth is the point. The right platform follows the workflow, not the other way around.
Recent automation and application work
Proof from the work, across Power Platform and custom builds.
Built around how each operation actually works, across both Power Platform and custom application development.
Beijer Ref: Power Apps
Five Power Apps delivered one at a time around real business processes, with structured data capture, defined workflow logic, controlled access and reusable Power Platform patterns across assembly configuration, customer-specific configuration, credit-application approval and manufacturing change requests.
Reusable patterns, proven across four manual processes. Read the Beijer case study →HBT Waratah Engineering: Time Management and Job Control
HBT Waratah Engineering needed more than a generic timesheet or job-tracking tool. Time management and job control had to reflect how work was planned, captured, reviewed and progressed inside the business, so Inlight IT delivered custom application development using open-source foundations where they earned the role.
Custom job-control software built to match how the work actually runs. Read the HBT case study →Questas: Custom Applications
Questas needed software that matched how the operation actually worked. Inlight IT delivered three custom applications on a production-grade open-source foundation: a manufacturing process and equipment-maintenance tool, a customer quotation application, and a production scheduling and planning tool.
Three production-grade custom applications built around the operation. Read the Questas case study →Questions that come up before the conversation starts.
Is this mainly Power Platform?
No. Power Platform is one strong path, especially for internal workflows inside Microsoft 365. Automation also covers custom workflow applications, integrations, reporting improvement and process-specific software where Power Platform or SaaS is not the right fit.
When is Power Platform the right answer?
Usually when the workflow is internal, structured, Microsoft 365-aligned and moderate in complexity, and needs forms, approvals, data capture or workflow automation without a full custom build.
When is custom development the better answer?
Usually when the workflow is highly specific, operationally important, long-lived, hard to fit into a low-code pattern, or where the business needs ownership without being tied to a SaaS vendor's roadmap and pricing.
Do you automate broken processes?
Not blindly. If the process is unclear, the first step is to map and simplify it. Automation works best when the workflow has a clear owner, clear stages, defined exceptions and a measurable outcome.
Can automation improve reporting?
Yes, and it is often the bigger long-term gain. Once a workflow moves out of inboxes, documents and disconnected spreadsheets, the business can see volume, status, bottlenecks, turnaround time and ownership clearly.
What is the first sensible automation project?
A workflow that happens often, causes visible friction, has a clear owner, can be standardised, and produces a measurable outcome. Starting with a useful, contained workflow creates patterns the next build reuses; starting with the most complex one slows everything down.
How does this relate to AI Applications?
Automation formalises the workflow. AI can assist, summarise, classify, triage or recommend inside it. Some opportunities need automation first, some can use AI immediately. The two landings are connected but solve different parts of the operating model.