SmartApps are the applications your teams run their processes in: approvals, reviews, requests, and collaboration inside the company and with suppliers and customers.
A SmartApp is screens, people, data and a flow, published as a version and run on live rows.
A SmartApp is an application for one business process. It has screens that people work in, a definition of who takes part and at which level or in which role, data handlers that read and write the rows the process is about, and a flow with the criteria that start it and move it along. You configure all four in the studio, test each piece as you go, and publish a version. From then on every start of the process gets its own instance, with its own process ID, its own workbench and its own log.
The data the app shows is read in place. A screen that lists open purchase order lines sends the filter and the columns to SAP or Oracle, and the rows come back within seconds; a screen that shows 12 months of history reads it from Snowflake or Databricks the same way. When a person approves, changes a date or releases a block, the app writes the change through the system's released interface and stores the acknowledgement beside the decision. The rows stay where they are, the access rules of each system apply at read time, and the audit record is complete by construction.
The same building blocks serve every app: components and layouts for screens, actions written as trigger, action and outcome, variables with four scopes, the expression editor with instant tests, and data handlers of five kinds. Learning them once is enough to build a supplier onboarding process, an S&OP cycle, a warranty check and a month-end checklist.
The six steps every app goes through. Each platform page below lights the step it explains.
Choose by the shape of the work: a hierarchy of people inside the company, or a process with lanes that can cross company borders.
For work that follows the organisation: approvals, reviews and sign-offs that move up and across functions. Define the hierarchy, attach a screen to each level, assign the people, then write the trigger and the flow criteria.
For any process with steps and decisions, including ones that cross into suppliers, carriers and customers. Draw the lanes and the boxes, attach screens, name the roles, write the criterion on each arrow.
A process app that starts from data: a criterion selects the records, each record gets its owners and its own flow, and the app follows every instance to the end.
Surveys, attestations and feedback: a screen that collects answers and a flow that routes them, with the results readable by every other app.
Learn five things once.
A screen is a layout of components: text boxes, dropdowns, grids, charts, buttons, pop-ups and panels, for desktop and for mobile.
Read the page →Each component can carry several actions.
Read the page →Screen variables live while the screen is open.
Read the page →Five kinds: a federated table, a saved query, a pipeline result, an API or file, and a device feed.
Read the page →Approvals with levels, alternates, delegates, series and parallel paths, time limits and escalation.
Read the page →One formula language for criteria, calculations and actions, with the live values of the row you pick shown as you type, so a rule is right before it is saved.
Read the page →The data fabric under SmartApps is what makes a cross-functional process one app.
A supplier price change touches the purchase order in SAP, the account in Salesforce, 12 months of history in Snowflake and a change ticket in ServiceNow. In a SmartApp that is one process with four screens, each screen bound to a data handler on the system that owns the object. The buyer, the seller, the controller and the IT owner each work in their own lane, on rows read within seconds from where they live.
Because the rows stay in place, the app is ready to build on the first day: register the handler, and the screen shows live data. The access rules of each system apply when the handler reads, so a person sees in the app exactly what they see in the source. When the flow ends, the app writes the price through the released interface of the ERP, stores the acknowledgement, and records the decision beside it in the lake for analytics.
The catalogue lists, for every app and every system, the objects the app reads, the fields its criteria use and the interface it writes with. How SmartApps connect explains the read and write paths for each system, and Across systems walks through the example above step by step.
Every entry in the catalogue names its screens, its data handlers, its trigger, its flow, its clocks and its measures, and shows what it reads in each system.
Collaboration across planning, sourcing and the supplier base, on live orders, stock and forecasts.
Open the group →Requests, approvals, suppliers and contracts, with the purchase order and the invoice read in place.
Open the group →Changes, deviations, releases and corrective actions on the shop floor and with suppliers.
Open the group →Warranty, returns, dock time, shipments and counts, close to the goods.
Open the group →Requests and changes to the records every other process depends on.
Open the group →Approvals and reviews on the journal, the budget and the credit line.
Open the group →Quotes, complaints, dispatch and account reviews, on CRM and ERP data together.
Open the group →Onboarding, expenses, findings and incidents, with the record of who decided.
Open the group →Access, assets and change, with the approval in the app and in the ticketing system.
Open the group →Configure, test, preview, publish, run, monitor, log.
The same seven steps for every app. Testing is part of configuring: an expression is checked against live values as it is typed, a screen is previewed on live rows as each role, and a version is published with a note.
Configuration effort for the 40 catalogue apps ranges from 2 to 10 working days for a production-grade version, and the first running screen takes about 30 minutes. The reason is that every part is configured, and tested where it is configured: a data handler shows its rows the moment it is registered, a criterion shows which live rows it selects as you type it, and a preview runs the app as any role you choose.
Once published, each start of the process is an instance with its own process ID and workbench, monitored until it ends and logged centrally from the first step to the last. Lifecycle covers environments, versions, promotion and the runtime.
Approvals, decision logs and access rules are part of the platform, so every app inherits them.
Every instance writes an append-only log: the person, the step, the values on the screen, the decision, the acknowledgement of any write-back and the version of the app. Approvals run on the workflow engine with levels, alternates, delegates and time limits, so a skipped or backdated approval is impossible by construction. Access rules apply at read time, from the same policies the rest of the platform uses, and the log records which rules applied to each read.
In the showcase estate, a quarterly certification of a revenue view ran as a three-stage approval: data engineering, the finance lead and the external auditor, in sequence, with the review pack generated by the platform. The whole cycle took 6 hours 14 minutes and the auditor signed with zero follow-up questions. Governance and audit has the full pattern.
The studio drafts screens, criteria and hierarchies from a plain description, and the same checks apply to a draft as to a hand-built app.
Describe the process in a few sentences: who takes part, what they decide, which records it is about and what should happen at the end. The studio drafts the levels or the lanes, proposes screens from the fields of the data handlers you point it at, and writes the criteria in the expression editor where you can read and test them. Screens can also be generated from rules you already have: a data-quality rule on a supplier record becomes the steward's correction screen, with the fields the rule names.
Only names and structure leave the platform when an external model is used: screen and component names, levels, handler definitions and criteria as text. The rows from your systems stay inside Lima. AI-assisted configuration shows the boundary and the review steps.
SmartApps run on the same query workers and the same connectors as the Data Fabric and the Backbone.
Read the page →SaaS, private cloud or on-premise, with the same three layers.
Read the page →One access model, one audit record, the AI boundary and the security packet. Apps inherit every control.
Read the page →Priced by platform capacity, with the apps included: as many apps, screens, instances and users as the capacity serves.
Read the page →Anonymised engagements and the showcase estate, each figure labelled.
A $100B semiconductor leader runs product warranty maintenance and critical-components planning on Lima, on 80 GB of new data a day.
A $20B telecom leader maintains global customer and product codes across three divisions in one collaborative app, feeding activation, forecasting and demand planning.
Logistics planners review stock re-routing recommendations in a decision app and release the accepted ones to the execution system; potential cash release above $500K.
Most application platforms keep app data in their own store and synchronise it from your systems. SmartApps read the rows where they are.
The comparison pages set out, with dated sources, how eight platforms answer the same questions: where the app's rows live, how a screen reaches SAP or Oracle, how approvals are modelled, what the audit record holds, how AI-assisted building works and what the pricing unit is. Each page also says when the other platform is the better choice.
Compare SmartApps with eight application platforms, with dated sources →
The people who own the process, with an application team where the process needs a new data handler or a write-back to a system connected for the first time. The studio is built for business configurators: clicks, plain sentences and instant tests. Application teams keep the gates: environments, promotion and the interfaces used for writes.
The screens read rows in place through data handlers, so an app can be built the day the system is connected. Where a process needs a prepared copy, for example 12 months of history at scale, the Backbone lands it in your lake and the app reads it there.
Through the same connectors the rest of the platform uses: released read interfaces and change capture for reads, BAPIs and IDocs or REST resources for writes. The connect page lists the paths per system, and every catalogue entry names the objects and interfaces for that app.
Yes. A portal screen is a screen assigned to an outside role. The supplier sees only the rows the access policy allows, works in their lane, and their steps are logged like everyone else's.
They finish on the version they started on. New starts use the new version. Both are visible on the monitoring board, and the log records the version of every step.
By platform capacity. Apps, screens, instances and users are included in the capacity tier; there is one price for the platform, written before the work starts.
Bring one process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.
