30 Jul Beyond dashboards: building an operational Customer Success application in Omniscope

I originally built the Simple CSM App to test how far an AI agent could author a real data application inside Omniscope. Once the prototype was working, another part of the experiment became more useful than the AI story itself: the same Omniscope project was acting as a workflow, an editable interface, a validation layer and a report.

The application covers customers, deals, renewals and activities. SQLite holds the committed records, while Omniscope loads and prepares the data, stages edits, validates changes and presents the working interface.

The Report brings customer context, commercial records, renewals and activities into one working interface.

A report that can do work

Most dashboards finish their job when somebody has understood the data. This project continues into the next action. A user can search the records, add a customer, update a deal or record an activity from the Report interface.

Those changes first enter editable Omniscope Data Tables, which act as the application’s working copy. The database remains untouched until the user selects Save to SQLite. At that point, a Python Custom Block checks the complete staged model and writes customers, deals and activities in one transaction. If one part fails validation, the transaction is rolled back rather than leaving the system half-updated.

That distinction is important. The interface feels immediate, but a form submission is still only a proposed edit until the persistence step succeeds. The Report reads the transaction result and can show whether the save was committed or rejected.

The form stages a Deal in Omniscope. SQLite changes only after the separate save operation passes validation.

One project, standard components and custom code

The workflow uses standard Omniscope components for most of the journey. Three SQLite source blocks read customers, deals and activities. Three editable and persisted Data Table blocks hold the working copies. A Report consumes those datasets together with the output from the save operation.

Custom development is used where it earns its place. One Python Custom Block creates the database schema and sample records. Another validates and persists the complete model. A JavaScript Custom View provides a focused CSM interface and uses the Omniscope Query and Workflow APIs to stage edits, run the required blocks and read the result.

The visible workflow shows the route from SQLite into the editable interface and back through the transactional save operation.

This mixture is useful because the custom elements do not hide the application inside an otherwise separate codebase. You can inspect the source blocks, staging behaviour, validation, forms, report configuration and database transaction in the same project. A builder can use standard components for the common work, then add Python or JavaScript where the application needs more specific behaviour.

The product lesson behind the experiment

I wrote separately about the AI-authoring experiment: OpenAI Sol and Terra 5.6 worked through Codex and, when necessary, operated Omniscope through its browser interface. That was a complex task and still a bit slow. My time went into defining the problem, refining the requirements and reviewing the result; I also asked the agent to write tests and used another model to review the code.

Here, the more durable lesson is about the shape of the resulting application. Data preparation, operational editing and reporting do not have to become three disconnected systems. In Omniscope they can remain parts of one visible workflow, with an interface designed for the people doing the work.

The same pattern could support many internal applications in which people need to inspect data and then act on it: reviewing records, adding context, correcting exceptions or moving an item through a defined process. The exact database and validation rules would depend on the use case. The point of the CSM example is to make the pattern concrete enough to inspect.

Where the prototype stops

This remains an internal prototype, not a production release. Production software needs proper authentication and permissions, secrets handling, testing, deployment, backups, monitoring, recovery procedures and operational ownership. SQLite also has to suit the expected scale and concurrency; it is one choice for this example, not a universal recommendation.

There are smaller prototype edges too. The custom view currently contains a hard-coded project path, and refreshing from SQLite replaces the staging tables, which means uncommitted changes can be lost. These are manageable engineering tasks, but they should remain visible rather than being polished out of the story.

You can open the public Simple CSM App, inspect it and download the project. For the full implementation—including the database schema, staging configuration, transaction logic and Custom View APIs, follow the step-by-step Help Centre tutorial.