Palantir Calls an Action a Single Transaction

本文另有中文版：Palantir 的 Action 是一筆交易：驗證、副作用、寫回、稽核綁在同一個定義裡

This piece continues part 1 of this series, which walked through the four layers Palantir’s documentation assigns to a decision — semantic, action, permission, lineage — and stopped at the definition of an action type. This piece stays inside the action layer alone: what an action is defined as, what has to pass before it can be submitted, where the edit actually lands, what runs afterward, what gets logged, who is allowed to press the button, and the ceilings Palantir’s own documentation lists along the way. Every Palantir docs page cited here was read in August 2026; none of it is versioned or dated on the page itself.

Palantir’s documentation defines an action in one line: “An action is a single transaction that changes the properties of one or more objects, based on a user-defined logic.” The word that carries the most weight in that sentence is “transaction,” and the official example on the same page shows what actually sits inside one. An Assign Employee action type bundles a parameter that lets a user type in a new role, a rule that automatically links the employee to a new manager, a notification side effect that tells the old and new manager about the change, and a submission criterion restricting the action to HR staff. All of that — parameter, rule, side effect, criterion — is one action type. The question this piece walks through is where the transaction boundary Palantir names actually sits inside that bundle.

An Action Type Binds Parameters, Rules, Criteria, and Side Effects Into One Definition

The action-types overview page defines an action type as a set of changes a user can make to objects, property values, and links at once, plus the side effect behaviors triggered on submission — a phrasing that is close to, but not identical with, the core-concepts definition already quoted in part 1, which additionally calls it a schema definition. The two pages use different wording for the same concept.

Inside that definition, parameters do the work of taking input: “Parameters are the inputs of an action type”, and each one is typed — a parameter can even be an object type itself. Rules fall into five kinds: create an object, modify an object, delete an object, create a many-to-many link, delete a link. Submission criteria decide whether the action can go through at all. Side effects send data out of Foundry. And when the five rule kinds cannot express the needed logic, an action type can call a function instead — Palantir’s documentation puts it plainly: “In some cases, however, simple rules are not sufficient to describe the changes that you want to make.” Palantir also states that the same action logic and validation can be reused consistently across every user-facing application built on the Ontology.

None of this becomes usable the moment it is saved. Palantir’s own getting-started tutorial builds a Demo Ticket object type and an action type on top of it, then notes that additional configuration is required before anyone can submit anything: “If running Object Storage v2, the user must enable edits with a toggle. If running Object Storage v1 (Phonograph), a writeback dataset must be created.” Saving the action type is not enough; the switch has to be flipped separately.

Three Checks Run Before an Action Can Be Submitted

The first check is visibility: “the user submitting the action must be able to view the edited object types and link types and their datasources, and pass the submission criteria”. If an object type only allows edits through actions, being able to view it is enough to edit it; if other paths to edit it exist too, the user needs separate edit permission on the writeback dataset. Creating a new object additionally requires visibility into the input datasource — without it, the action fails outright.

The second check is the submission criterion itself — the condition that decides whether the action can be submitted at all (defined in part 1). It can combine parameter values, which is how business logic gets encoded into edit permissions.

The third check runs at the API layer, and it is narrower than either of the first two. The Validate Action endpoint states its own limit directly: “For performance reasons, validations will not consider existing objects or other data in Foundry.” Any check that can only be decided by looking at an existing object falls outside what this endpoint covers. The OSDK carries a related constraint of its own: “It is not possible to return edits and validateOnly at the same time.” In practice, Workshop only makes its submit button available once every parameter has passed validation, and the OSDK’s applyAction call simply returns whether a given call was valid or invalid.

After Submission, Edits Land in a Funnel Queue, Not the Backing Dataset

Once an action is submitted, the Actions service sends a modification instruction into a queue managed by the Funnel service, and Palantir guarantees that any object read occurring after that instruction is sent will contain the edit. Object Storage v2 runs fewer version checks than v1 does, and Palantir states the trade-off directly rather than leaving it as an outside criticism: fewer StaleObject conflicts, at the cost of weaker guarantees.

If the same object receives both a datasource update and a user edit at close range, two conflict strategies exist. The default is “Strategy 1: Apply user edits (default)” — the edit always wins, regardless of what the datasource sends afterward for that property. The alternative strategy compares timestamps and only keeps the edit if it is newer than the datasource’s own timestamp for that field. Deletion is not treated as an edit at all; a deleted-then-recreated object does not inherit its earlier edits. And even when the datasource has nothing new to offer, Palantir still runs the persistence job on a fixed cadence: “live pipelines will run every six hours regardless of any explicit backing dataset update”.

Two separate write-back mechanisms get confused with each other constantly, and they need to stay apart. A user’s edit to an Ontology object never reaches the dataset backing that object type — the only optional next step is materializing the combined state into a different dataset. Writing to an external system altogether is a different mechanism, the webhook, covered below.

Materialization in Object Storage v2 Is Optional

Under Object Storage v2, materializing the combined state of source data and edits into a dataset is not a prerequisite for editing — a single toggle in the Ontology Manager enables user edits without it. Palantir states materialization exists mainly to feed downstream Foundry pipelines. Where it is configured, propagation runs one of two ways: automatically, with a lag of a few minutes, or on a schedule that rebuilds at most every six hours. Either way, Palantir is explicit about what persists: “only the latest snapshot is guaranteed to be available” — historical states require a separately built transform. Streaming-backed object types do not yet support actions or user edits at all, and Object Storage v1 (Phonograph) is in its planned deprecation window, unavailable after June 30, 2026.

Webhooks Split Into Two Modes With Opposite Failure Behavior

Side effects fall into two categories: notifications and webhooks. A notification’s content is generated from the state of the Ontology before the current action’s edits are applied, and a recipient never receives data they cannot view; if the default permission requirement is not met by every recipient, nothing is edited and nothing is sent. Recipients cap at 500 per action, or 50 when the content is rendered from a function.

The webhook is where writing to an external system actually happens, and Palantir’s own comparison table splits it into two modes with opposite behavior. A writeback webhook runs before object changes; if it fails, the failure is shown to the user and nothing else changes. A side-effect webhook runs after object changes; failure is not shown, and the user may already have seen a success message by the time it happens. Palantir describes the writeback mode’s guarantee carefully: “This behavior enables some degree of transactionality between Foundry and the external system.” Only “some degree” — the external call can still succeed while the Ontology change fails, which is why an action can only be configured with a single writeback webhook. Side-effect webhooks carry no such constraint: “By default, the newly added webhook is configured as a side effect” — multiple can be attached to one action, and they run in no guaranteed order — the documented use case is best-effort notification or writing to several external systems at once.

Reverting an action is often assumed to undo this whole bundle. Palantir’s documentation states the actual scope precisely: “An action revert only reverts the edits to the object instance, but it will not revert side effects, such as notifications or webhooks, nor will it call them in the same way that the applied action would have.” A revert is only possible if the action is still the most recent edit to the object — any later edit, even to an unrelated property, blocks it — and reverts only work on Object Storage v2. Palantir’s own word for this is revert, not rollback, and it is scoped to object edits alone.

Action Log Automatically Records the Submitter and Primary Keys, Not Property Values

Every action submission auto-generates a log entry recording the submitter’s Multipass user ID, a timestamp, and the primary keys of every object the action edited. The documented limit is specific: “Note that storing properties of edited objects other than the primary key is not supported.” That does not mean the audit trail is limited to primary keys — the log can be separately configured to also capture a summary string, parameter values, or properties of objects the action did not edit — but before-and-after values of the edited properties themselves are not part of the default schema.

A finer-grained history requires turning on a separate feature, user edit history, and Palantir is explicit that turning it on is not retroactive: “Any changes prior to the activation of this feature will not be tracked.” Migrating from Object Storage v1 to v2 preserves only the Action Logs, not the rest of the edit history. Palantir’s fiscal year 2025 10-K also references audit logs, in a passage about the platform maintaining logs that let authorized users investigate past misuse — but that passage describes platform-wide audit logging, not the Actions mechanism covered here.

Workshop, OSDK, Automate, and AI Agents Trigger Actions Under Different Rules

A person can trigger an action through a Workshop button, the OSDK, or a direct API call. The API carries a detail that is easy to miss: “Note that a 200 HTTP status code only indicates that the request was received and processed by the server” — success has to be read from the response body’s validation result, not the status code.

Automate’s action effect runs an action automatically when a condition fires, and it runs under the automation’s owner: “This means that the action will be run on behalf of the owner of the automation.” The owner’s submission criteria are what get evaluated, the owner’s name is what shows up in edit history and audit logs, and the owner can be a third-party application’s service account rather than an individual. Automate’s execution guarantee is explicit about what it is not: “Effects follow at-least-once execution semantics rather than exactly-once guarantees” — which means designing the action or function on the receiving end to be idempotent.

Three separate interfaces let AI trigger an action, and Palantir’s documentation gives each one its own sentence rather than one shared rule. AIP Logic’s Apply action block can call an action deterministically, but nothing reaches the Ontology unless it is called that way: “The Ontology will not be edited unless the Logic function is executed from an action, even if the function contains an Apply action block.” Chatbot Studio (formerly Agent Studio)‘s Action tool “can be configured to run automatically or to run after confirmation from the user” — not fixed either way. And the why-ontology page’s fictional example, built around a manufacturer called Onyx, describes the default as staged: AI-triggered actions can only be staged for human review before being handed off — but the same passage continues, “Onyx is able to carefully choose whether any trusted, well-tested AI processes can automatically close the action loop without human review.” Staging is the default case in a fictional worked example, not a rule stated anywhere else in Palantir’s documentation.

Official Docs List Numeric Ceilings on Every Action Submission

A single action submission is capped at 50 object types and 10,000 objects; the size of any individual edit is capped at 32KB on Object Storage v1 or 3MB on v2. On batching, the documentation states: “An action can be called a maximum of 10,000 times in a batch. This limit is reduced to 20 when the action is function-backed and the function is not configured to use batched execution”. The batch API endpoint carries its own, separate cap: “Up to 20 actions may be applied in one call” — and that endpoint does not support parameter defaults or notifications.

A branch is for testing only: “Action edits on a branch are for testing only and will not be merged back into main”. Webhooks in particular are off by default on a branch, with the reason stated directly: “By default, webhooks do not execute when an action is applied on a branch. This behavior is to prevent accidentally writing to external systems while in a testing environment.” Two community-forum posts, each from a single anonymous account, describe running into these edges in practice. One, dated June 24, 2026, reports: “Being not able to run actions in the branch.” The other, dated April 5, 2026, describes the split between Object Reference and Object Set action parameters this way, spelling included: “I find the differentiation between Object Reference and Object Set in the Action Paramaters to complicated for Non Technical User.” Both are single posts by individual users, not evidence of a wider complaint.

What Six Write-Back Products’ Official Pages Say About Validation, Side Effects, and Audit

Checking six reverse-ETL, workflow, and business-application platforms against their own official pages, on five questions — does the product write to external systems, validate before submission, run side effects, keep the source separate from edits, and log per submission — produces a simple result: either the official page has a sentence addressing it, or none could be found. “Not found” describes a gap in the page, not a claim that the product cannot do it.

Dataverse spreads validation, side effects, and audit across three separate pages and three separate components — business rules, Power Automate, and auditing. Palantir binds the same three, plus write-back, into a single action-type definition, which is why the last row is the only one that fills all five columns. Looker’s Action Hub does write back to external systems; a semantic-layer product category is not automatically without a write-back path.

An Action Type Binds Four Things, but the Transaction Holds Only Object Edits and the Writeback Webhook

What is hard here is not any one of pre-submission checks, side effects, write-back, or an audit trail on its own — each of those exists as a separate product category. What is hard is binding all four into one action-type definition, triggered by one submission. And Palantir’s own documentation draws the transaction’s boundary more narrowly than that binding suggests: object edits sit inside it, along with a writeback webhook if one is configured, because a writeback webhook’s failure blocks the whole submission; every side-effect webhook and every notification runs outside it, asynchronously, best-effort. The audit trail auto-records primary keys, not before-and-after property values. Automation runs at-least-once, not exactly-once. That is this article’s judgment, not Palantir’s — no Palantir document calls Actions a differentiator or a core capability.

HASH’s company blog raises a different objection entirely, about lock-in rather than this transaction mechanism: data lives inside Palantir in a proprietary format, and “any migration would be long and expensive” (HASH company blog, April 3, 2025). That is a cost of leaving the platform, not a claim about how the transaction itself is built.

Back to the opening line — “a single transaction.” The boundary of that transaction is exactly what separates the two rows of Palantir’s own webhook comparison table: before object changes, and after. Next in this series: how far a semantic layer and an action layer can each get without Palantir.

Frequently Asked Questions

Q: Do an Action’s edits get written back to the source dataset? No. User edits are always written to a writeback dataset or the Object Storage v2 index, never to the dataset backing the object type itself. Seeing the source data combined with the edits requires a separate, optional materialization step, and that materialization guarantees only the latest snapshot.

Q: If a webhook fails, is the change to Foundry cancelled? It depends on the mode. A writeback-mode webhook runs before object changes, so a failure stops the whole action. A side-effect-mode webhook runs after objects have already changed, and Palantir describes it as best-effort — the user may already see a success message before it fails.

Q: Can an AI agent submit an Action directly? Three different interfaces carry three different rules, and Palantir’s documentation does not collapse them into one policy. In the why-ontology page’s fictional example, AI-triggered actions are staged for human review by default, but a trusted, well-tested process can be allowed to close the loop automatically. Chatbot Studio’s Action tool can be set to run automatically or after user confirmation. AIP Logic’s Apply action block writes nothing to the Ontology unless a Logic function is actually executed from an action.

Q: How many objects can a single Action edit? Palantir’s documentation lists a limit of 50 object types and 10,000 objects per submission, with a per-edit size cap of 32KB on Object Storage v1 or 3MB on Object Storage v2. A batch call is capped at 10,000 executions, dropping to 20 when the action is function-backed and not configured for batched execution.