Apps With an Engine: Taking a Complex Analyst Studio Flow to the Front End

Last week on The Weekly Cup of Joe, we built an analytic flow together in Incorta Analyst Studio. We pulled tables from an Incorta physical schema, ran a revenue analysis across brick and mortar stores, and isolated what drove each store's gains or losses every month. Basket size, foot traffic, and product pricing all got their turn under the microscope.

If you missed that session, I'd go back and watch it. This week we turned the volume up to eleven. I wanted to show what happens when one of these flows gets big, and what it could look like to put a real application on top of it.

When a workflow hits 300 recipes

Most of the time, an Analyst Studio workflow looks like the tidy transformation we built last week. In the field, we see something bigger. One demo workflow I showed has over 300 recipes and five separate outputs. Some customers run 500 or 600 recipes at once.

That looks monolithic at first glance. Look closer and you'll see something useful happening. Those five outputs all share the same roll-up logic, then branch into their own calculations. Each output runs about 60 transformations of its own.

Build the same thing in a physical schema and you'd write a materialized view for the shared roll-ups, then stack more materialized views on top for every derived analysis. Each view produces exactly one output, so you end up duplicating logic over and over. A single workflow compresses all of that into one place.

Who fixes it when something breaks?

Data changes every week and every month. New values show up. Mapping files drift. Analytics this robust need room to adapt on the fly.

Now picture handing that 300-recipe workflow to a business user and saying, "Let me know if anything goes wrong." When a run fails, how do they find the problem? How do they fix it? That's a lot to ask.

The same question applies to AI apps. Building an app on top of your Incorta business views and physical tables is easy today. You write SQL to query the data, and a lot of the last-mile transformation logic ends up living in the application code. That works on day one. Three months later, when the data has evolved and a number looks wrong, someone has to dig through React code to find out why.

Let the app drive the engine

So we ran an experiment in what I'll call Incorta Labs. We pulled that last-mile logic out of the application and pushed it down into Analyst Studio. The app drives the flow. It passes values into the workflow, and the workflow passes results back to the app.

You get a fully auditable, traceable experience that stays easy to maintain. When something goes sideways, you can click into any recipe and inspect the data, the configuration, and the lineage of the logic. Compare that to troubleshooting a pile of code. I think most teams would pick the visual flow every time.

The demo: a financial consolidation app

I kept the demo workflow simple on purpose so the idea wouldn't get lost in the clutter. It's a financial consolidation process that prepares data for Workday Adaptive Planning. Three ERP systems feed it, one each for APAC, LATAM, and EMEA. The flow conforms them to a common grain, applies mappings, and builds the Adaptive output. (Many of our customers run this kind of process across 25 or 30 ERP systems.)

On top of that workflow sits a front-end app. Here's what it does.
‍

It controls which logic runs. Each container in the workflow holds a chunk of logic, like one ERP ledger or one step in the process. In the app, I unchecked the LATAM box, and the visual grayed it out. The next run skips that logic entirely.

It passes parameters into the flow. Normally, switching the consolidation period to May means opening the flow and updating the same formula in several places, then making sure they all match. In the app, you pick a reporting period once. That value flows straight through the whole workflow.

It surfaces data quality tests. A clean run can still produce bad data. So we built validation checks throughout the flow. One join tool, for example, matches the APAC ledger against a mapping file. If any record comes out the right side of that join, something in the ledger is missing from the mapping file. Each test can be set to warn or error, and the results appear right in the app.

It lets you fix exceptions in place. When I ran the demo, the app refused to load files until I handled the exceptions. The Exceptions tab pulled the failed records back from the flow. I remapped a planning level, updated a BOMA code, and saved both changes to the mapping table. In this demo the mapping files live in SharePoint, so the app writes back there. You could write back to Incorta or another source system just as easily. We also surfaced those mapping tables inside Incorta, with a full audit history and a reason captured for every change.

It takes you into the workflow when the logic is the problem. Sometimes the data is fine and the process needs work. From the app, you can open the flow in Analyst Studio, find the join or filter causing trouble, and fix it there. The app also shows a map of the analytic flow, so you can see exactly where each issue happens.

After I fixed the exceptions and reran, every test passed. The data moved all the way through, ready for sign-off and loading into Adaptive.

‍

Reach out to request a deeper demo, or join us live on a Friday for the next Weekly Cup of Joe.