Skip to content
Power AppsPower PagesFabricDataverse

Workflow Engine

One workflow experience across Power Apps code apps, Microsoft Fabric apps and Power Pages. The frontend stays familiar while the backend data store fits each deployment.

View government demos
Discuss your workflow
A dashboard in the NSW showcase, with one request awaiting a response and demand signals shown as supported demand, work in progress, requests awaiting a response and decisions recorded

See the engine in context

Government workflow showcases

These Data-Driven AI product demonstrations use synthetic people and records. They are not government systems or production deployments. The state marks identify each design-system treatment, not government endorsement.

One experience, different data layers

Keep the workflow experience as the host changes

The same React screens guide people through intake, routing, assessment and approval. The engine runs in Power Apps code apps, Microsoft Fabric apps and Power Pages. Each deployment connects those screens to its own data store. People see the same workflow steps.

Forms, questions, routing rules and approval paths live in configuration. Administrators can change the process without a new frontend release.

Discuss your workflow

The Power Apps code app deployment uses Dataverse. We scope the data store and access model for a Fabric app or Power Pages deployment separately.

Frontend
A consistent React and TypeScript workflow UX
Host
Power Apps code apps, Fabric apps or Power Pages
Backend
Data store and integration fitted to the deployment

What you don’t have to build

From intake to portfolio, on one engine

The engine holds no department names and no organisation-specific logic. Automated build checks enforce that, so one engine serves many processes.

Authoring

Sections, questions, help text and answer types are edited in a builder. A live preview runs the real rule engine, and publishing freezes that version while forms in flight keep serving.

Conditional logic and validation

Show, hide, require or lock any question or section from the answers so far. Nested AND/OR groups handle a rule like “A or B, but not C”.

Catalogue lookups

Type-ahead search across approved products, projects, services, assets and people. A “not listed” path stays open, so a missing entry never blocks a submission.

Routing, triage and approvals

Answers route a request to one or many assessment teams. A summary before submit names every team it will reach. Queues, delegated approval and escalation follow.

Assessment and portfolio

Requests score against configured criteria and weights, and the screen shows each criterion, its weight and its contribution. The portfolio view ranks everything in flight.

Records and versioning

A submitted record always renders against its own template version, and the data layer refuses to move a record between versions.

Explore the NSW screens

Watch a request travel from intake to a ranked portfolio

Intake, routing, scoring, portfolio and authoring, captured from the NSW showcase. Every person, record, decision and date in it is synthetic. Select a stage to read what it demonstrates, or open a screenshot full size.

Intake form

The form is rendered from a definition, not hand-built

Labels, help text, control types, options, defaults and validation all arrive as metadata. A new question is a configuration record, which is why the process can change without a release.

NSW Design System Persona: Alex MorganSynthetic data Open the NSW showcase

Routing review

Where the request will go, before it is submitted

The routing decision is put in writing up front: every assessment team the answers resolved to, what each of them covers, and whether that route is required or selected. The requestor confirms with the destinations on screen.

NSW Design System Persona: Alex MorganSynthetic data Open the NSW showcase

Assessment

The reviewing team sees its own queue, and nothing else

Inside a request a reviewer gets its progress, the other teams involved, the demand health brief and any information they have asked the requestor for. Work outside their scope is absent from the view rather than greyed out.

NSW Design System Persona: Sam WhitfieldSynthetic data Open the NSW showcase

Demand portfolio

Every request ranked, with its pathway and forecast date

Everything in flight is ranked by priority score, with a recommended pathway of fast, standard or complex beside a forecast date. The ranking is not a black box: the criteria, their weights and the pathway thresholds are explained on the screen that applies them.

NSW Design System Persona: Jordan LeeSynthetic data Open the NSW showcase

Template builder

The administrator changes the process, not the code

Sections, questions, answer types, help text and required-ness are edited as metadata beside a live preview of the form a requestor will fill in. Publishing freezes that version, and forms already in flight keep serving the version they started on.

NSW Design System Persona: Casey NguyenSynthetic data Open the NSW showcase

The Queensland and Victoria showcases use the same engine with state-specific design-system styling and synthetic records. Open the government demos above.

Ownership

You own the code on delivery

We deliver the engine as source code to your repository and the Microsoft environment you choose. You own the code on delivery. There is no engine licence fee or per-form or per-workflow charge. Your administrators update the rules as configuration. Your platform’s hosting and data service arrangements remain yours.

Where it fits

Fit the data layer to your environment

The Power Apps code app uses Dataverse for configuration and records. Fabric apps and Power Pages need data and access connections fitted to those hosts. We scope sign-in, permissions, attachments, notifications, reporting and environment promotion with your platform team.

The design system is a build-time choice rather than a rebuild. The NSW showcase loads the NSW Design System, the Queensland showcase uses the Queensland Government Design System, and the Victoria showcase is Ripple-styled with token values transcribed from a pinned release. All three use the same engine and form templates. The NSW and Victoria builds have been tested for keyboard, landmark and reflow behaviour from 320 to 1920 pixels. An assistant panel answers questions about the requests and routing on screen, names the record behind each answer, and has a documented path to a Copilot Studio agent grounded on your own Dataverse.

Start with one workflow you can check

Bring its form, its rules, its assessment teams, and what currently goes wrong.

Discuss your workflow
View all solutions

Want to learn more?

Explore the rest of the site or get in touch with the team.

Back to home

A Microsoft Frontier Firm delivering Microsoft Fabric data platforms, Azure analytics and Agentic AI for Australian government and enterprise.

Hosts of the Sydney Databricks Meetup

Explore

Get in Touch

Evidence & Community

Office

  • Sydney, NSW
    111 Harrington, The Rocks NSW, Australia, 2000
  • Melbourne, Victoria
    311 Lonsdale, Dandenong 3175, VIC, Australia

Assurance and credentials

Microsoft Solutions Partner with Advanced Specialization in Analytics
ISO/IEC 27001 certified ISO 9001 certified ISO/IEC 42001 verified
FinOps Foundation General Partner
Microsoft Fabric Featured Partner Carbon Neutral Organisation SCM0020 NSW Government ICT Services Scheme Prequalified supplier
CloudMonitor FinOps Certified Specialty Solution

CloudMonitor · FinOps for AI

For state and federal government teams, CloudMonitor brings billed Azure AI costs, connected GitHub Copilot usage and budget signals into one review. Missing provider feeds stay labelled, and accountable owners keep the decision.

Explore CloudMonitor FinOps for AI

© 2026 Data-Driven AI

Terms & Conditions

Privacy & tracking

Government Information

Sitemap