What is Palantir - Part 5: Apps without a dev team

Part 4 ended with an analyst who could name the supplier behind Plant 7's late deliveries and show the eighteen-month slide behind it. Naming the supplier isn't switching it. That job belongs to a procurement manager, and procurement managers don't work in analysis tools.

So somebody has to build them a screen.

This is part of a series on what Palantir actually does, each part building on the one before. Part 1 covered what Palantir and its Foundry platform are at a high level. Part 2 covered how data gets into the Ontology. Part 3 built the Ontology itself, the objects, links, and actions that model a business. Part 4 put an analyst on top of it. This part builds the screen the operator works in, and shows what each step of that build looks like.

What the screen normally costs

Start with what that screen costs to build the usual way. The data lives in a warehouse, so an API goes in front of it, and the API needs authentication wired to the identity provider. The screen has to write back to the ERP, which means a service that makes that call and a decision about what happens when it fails halfway through. A frontend repository, a build pipeline, and a staging environment sit around all of it. Somebody has to own the whole thing for as long as the screen is in use.

Most of that work builds the scaffolding that holds the screen up.

On Foundry that scaffolding is already standing, because the app reads the Ontology directly. Workshop is Foundry's application builder, and what it produces has no frontend codebase and no API layer of its own. Palantir's documentation says Workshop applications "aim to be as user-friendly and high-quality as custom React applications".

Where the screen comes from

A build starts by pointing at an object type. Drop an object table onto the canvas and choose Supplier, and the screen has real data in it: the manager's region, sorted by on-time delivery, one row red this morning. Nothing was queried. The widget reads the object type modelled in Part 3.

Selecting the red row opens the supplier's object view. It shows the object's properties and its linked objects one link away, including its open purchase orders, its plants, and its recent actions. Each is reachable without a query because the links are already modelled. The analyst's conclusion from Part 4 sits on the record too, left as a comment on the object rather than a line in a slide.

There are many more widgets than tables and charts. There's a Gantt chart, a pivot table, a PDF viewer with keyword search, an action log timeline, and an AIP Analyst embedded as its own widget so AI-assisted analysis sits on the same screen instead of in a separate chat window.

Work another Foundry tool already produced drops in as a widget too. Foundry's Quiver chart of Plant 7's eighteen-month delivery slide, or a graph of that supplier's network from Foundry's Vertex, is the one the manager sees, not a Workshop chart someone remade to match it.

Making the widgets talk

Each widget is configured with input and output variables, so one widget's output becomes another's input. The supplier selected in the object table is an output variable, and the object view and the action form both read that selection as their input. Select a different row and both update around it.

A variable keeps its own list of what uses it. The builder can see which widgets read a variable before changing anything that feeds it.

Interactivity runs on events: selecting the red row can open an overlay, switch a tab, or recompute a variable. Two events are worth naming because they connect the screen to AI models and agents. One streams an LLM's response straight into a variable, with the model and temperature set on the event. The other sends a prompt built from the screen's live state, the currently selected supplier included, to an AIP Assist agent. Part 7 covers the models and agents used here.

A number nobody stored

A widget's content can be backed by real code. A function on an object is logic written against Ontology objects, traversing their links rather than reading a single row. That function can back a variable, so a widget shows a computed value nobody stored. It can also back an action, so submitting it runs that logic as part of the writeback.

Plant 7's days of cover is that kind of value. The function follows the supplier's links to its purchase orders and calculates the value from their lead times when the screen asks for it. No column stores it. The configuration panel wires the function's inputs to the module's own variables, so the number recomputes when the manager selects a different supplier.

The button and its form

A dashboard shows state. An operational app changes it. The difference is the action sitting next to the data.

"Switch supplier for Plant 7" was modelled in Part 3 as an action type, with parameters, validation rules, and permissions. In Workshop, that action appears as a form generated from the action-type definition itself. The form is derived from the definition rather than built by hand. Its fields and its writeback therefore come from one source. The interface and the effect can't fall out of sync as the action changes.

The manager picks the replacement from a dropdown that only shows suppliers matching the case: filtered on region and material inferred from the record, so a supplier that fails either is never offered. The picker never exposes objects the manager can't access. Whatever a filter didn't cover gets checked against the action's submission criteria: approved in the region, cleared for the material, submitted by someone with the authority to do it. Then the change applies as one transaction.

Testing the switch before making it

Before making the switch for real, the manager can test it. A Workshop scenario creates a separate version of the Ontology's data and applies that same supplier switch to it, without touching the live record.

The result is not a separate estimate. A scenario runs the real action against the real logic, so days of cover recomputes through the same function the live screen uses. Nobody builds a what-if model, and there is no second model to drift out of step with the first. That is what separates this from the spreadsheet that usually does the job.

It also changes the argument in the Tuesday review. The manager can model one replacement, then another, and put the resulting numbers side by side. The case for a supplier becomes something the room can read rather than something someone asserts. A scenario stores only what changed from the base Ontology, not a full copy. It cannot be changed once created, and each one is capped at 50 actions. Those limits are deliberate: a scenario is a quick check, not a parallel system for somebody to maintain. The manager presses the real button once the modelled result passes their check.

What one press does

Submitting the form writes an action log entry, a separate record linked to the supplier rather than stored on it. By default it records who submitted the switch and when. If the log is set up to keep them, it also records the parameters, including which replacement supplier was chosen. The next person who opens that supplier can reach that linked history from the supplier object.

Set up as a notification on the action type, the switch can message the plant manager or the next-shift lead automatically, each person gets their own message instead of a shared thread, and nobody has to write an email. Foundry only sends a notification to someone allowed to see the data in it, so the alert cannot show a reader more than they are cleared for.

Set up as a webhook, the same press can send a request to a configured external system, such as the ERP where the supplier change normally happens. That request runs as a side effect, after the manager sees the success message and outside the single Foundry transaction, and a failure is not reported in the action's success message. If an action has more than one webhook, they run in no particular order. It extends what the action can reach, but it sits outside the single transaction described above.

If the manager picks the wrong supplier, the success message offers an undo, though only to the person who submitted it, and it rolls back the Foundry edit alone. A notification that has already gone out, and a webhook that has already fired, do not unwind. That is why the action log is the lasting record.

Nobody exported a list into a spreadsheet, and nobody re-keyed a supplier code into an ERP screen.

Releasing it like software

An app that works in a Tuesday review then has to work in daily use. Workshop modules are published and versioned, so the builder's draft stays separate from the operator's released version. The team edits and previews changes on the draft while operators keep using the last published version. A new version reaches them only when someone releases it.

The app lives as configuration on the model, not as a frontend codebase. Change that configuration, publish a new version, and operators get the update. There's no separate application to recompile and redeploy, so changes do not wait on a development cycle. And because it's configuration, the person who builds it can be the analyst from Part 4, or a builder who sits inside the procurement team and knows what the Tuesday review actually argues about.

Who may press which button

Part 4 stopped at reading the data. Here, the manager also needs permission to act on it. To submit an action, a person needs to be able to view the object and link types the action edits, and their datasources. New object types allow edits only through actions by default. A person can therefore run the switch without holding open edit rights on the supplier record. What a person can see still follows the model. A manager in another region opens the same app and sees their own suppliers, without anyone writing a filter to hide the rest. The app uses the permissions and visibility already defined in the model.

What Workshop is not

Keep heavy analysis in the Part 4 tools. Workshop is for the point where someone needs to act. Slate is Foundry's other application builder, a better fit when a build needs custom HTML, CSS, or JavaScript rather than this part's no-code, object-and-action pattern. A read-only KPI wall nobody acts from is fine where it is. Workshop is worth using when people need to see and act on the same screen. When the app has to live outside Foundry entirely, for suppliers to use or inside a portal you already have, it is built against the same Ontology through the developer path. Part 8 covers that.

The warning from Parts 3 and 4 matters more here. An app is only as good as the verbs beneath it. If the domain was modelled without action types, Workshop produces another dashboard. The modelling work decides whether the operator gets a button.

The supplier's story so far: connected in Part 2, modelled in Part 3, found by an analyst in Part 4, and now switched by a manager who never left one screen, with the decision on the record. Every step so far has needed a person watching. Part 6 covers rules that flag the supplier the moment delivery slips, and the testing required before automation can act on its own.