When a Palantir Action Succeeds, What Has Changed?

本文另有中文版：Palantir Action：送出成功，哪些東西改好了？

Assign Employee is the example action type in Palantir’s documentation. It bundles four things:

• a parameter where a user types in a new role,
• a rule that links the employee to a new manager,
• a notification that tells the old and new manager about the change,
• a submission criterion that restricts the action to HR staff.

When an HR user presses submit, does all of that complete together? And suppose the action also carried a webhook that writes to an outside system. If one step failed, would the others be undone?

The 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.

That sentence can be read as “everything succeeds or fails as a unit.” The mechanisms the documentation lists give a much narrower guarantee.

This article’s view is that the value of an action type lies in the first half: it puts the conditions and the effects of one submission into one definition. The second half has a limit. A side effect on an outside system does not necessarily succeed together with the object edit, and it cannot always be undone together with it.

This piece continues part 1, which looked at how the Ontology ties data, logic, actions and permissions together. This piece follows one Assign Employee submission: what it must pass first, where its edits go, what happens when something fails, and what can be checked afterward.

Before submission: who can submit, and under what conditions

The action-types overview page describes an action type as a set of changes a user can make to objects, property values and links at once, plus the side effects triggered on submission. Each of the four things in Assign Employee maps to a part of that definition. The parameter is the input. The rule decides what changes. The submission criterion decides whether the action can be submitted. The side effect sends data out of Foundry. When rules cannot express the logic, a function can drive it instead. Palantir also says the same action logic and validation can be reused consistently across every user-facing application built on the Ontology.

For the HR user to submit at all, visibility comes first: “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” (permissions page).

Submission criteria can combine parameter values, which is how business logic gets encoded into edit permissions. “HR staff only” is that kind of condition.

There is also an optional API pre-check, Validate Action. It answers whether an action can run with a given set of parameters, and its response evaluates the parameters and the submission criteria. It states its own limit:

For performance reasons, validations will not consider existing objects or other data in Foundry.

Anything that requires looking at existing data, such as whether a primary key is already taken or whether a user ID exists, is not checked.

So a passing pre-check does not guarantee that a real submission will succeed. It is an endpoint you can call, not a gate every submission has to pass. A real submission still has to pass permissions checks and the submission criteria.

After submission: where the new role is written

A user’s edit to an Ontology object is not written to the dataset backing the object type. To let downstream Foundry pipelines read the combined state of the source data plus edits, you can set up materialization, which writes that state into a separate dataset. Under Object Storage v2 this is optional.

The documentation is plain about what persists: “only the latest snapshot is guaranteed to be available” (materializations page). Object Storage v2 does not guarantee retention of historical snapshots; preserving them requires a separately built transform.

Writing to an outside system takes a different route, the webhook. The two should stay apart: edits go into the Ontology, and webhooks change the outside.

Notifications and outside systems: two webhook modes that fail in opposite directions

Side effects fall into two categories: notifications and webhooks. Assign Employee’s message to the old and new manager is the first kind. A notification’s content is generated from the state of the Ontology before the 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, Palantir says nothing is edited and nothing is sent.

The webhook is where writing to an outside system actually happens, and it has two modes:

Start with writeback. It runs before object changes, and if it fails the failure is shown and nothing else changes. Palantir describes the guarantee carefully:

This behavior enables some degree of transactionality between Foundry and the external system.

Only “some degree.” The documentation goes on to say that if the request to the external system fails, no changes are applied to the Ontology, but the external request can succeed while the Ontology change fails. In that case the outside system has changed and the Ontology has not. The documentation also says that because the action stops being applied when a writeback webhook fails, an action can have only one writeback webhook.

Now the side effect. A newly added webhook is configured as a side effect by default (set-up-a-webhook page). It runs after the objects have changed. Its failure is not shown to the user, who may already have seen a success message by the time it runs. Several can be attached to one action, in no guaranteed order.

Undoing it: what a revert can undo

A revert is often imagined as undoing the whole bundle. The documentation is exact about its scope (action-reverts page):

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.

Three limits come with that:

• A revert undoes only the edits to the object. Notifications and webhooks are not undone, and they are not called again in the way the applied action called them.
• Once the object has been touched by any later edit, even to a different property, the action can no longer be reverted.
• Reverts work only on Object Storage v2.

Back to Assign Employee: even if the object edits are reverted, the notification the old and new manager already received is not taken back. Whatever a writeback or side-effect webhook already did to an outside system is outside what a revert handles.

Checking afterward: what the action log records and what it doesn’t

The action log is a record you configure on an action type. Once configured, each successful submission adds an entry recording the submitting user’s Multipass ID, a timestamp and the primary keys of the objects edited. The documentation states a specific limit (action-log page):

Note that storing properties of edited objects other than the primary key is not supported.

Property values of the edited objects, other than the primary key, are outside what it supports.

That does not mean the audit trail holds only primary keys. The log can also be set to store a summary, parameter values, and properties of objects the action did not edit. None of that amounts to before-and-after values of the edited properties. A per-object history of each edit needs a separate feature, user edit history, and Palantir says (user-edit-history page):

Any changes prior to the activation of this feature will not be tracked.

Submissions no one clicks: a 200 or an automatic run is not “done” either

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.” (Apply Action API page) A 200 does not mean the action succeeded. Read the validation result in the response body.

Automate’s action effect runs an action automatically when a condition fires, and “the action will be run on behalf of the owner of the automation.” (action-effects page) The submission criteria are checked against the owner, the owner’s name is what appears in edit history and audit logs, and the owner can be a third-party application’s service account.

Its guarantee is explicit about what it is not: “Effects follow at-least-once execution semantics rather than exactly-once guarantees.” (effect-settings page) The same effect may run more than once, and Palantir recommends designing the operation to be idempotent.

Reading it: bound in one definition does not mean they succeed or fail together

The conditions and effects of one submission hang on one action type definition: the submission criteria, the object edits, the notifications, the webhooks and a configured action log. This is the value of an action type.

The sections above also drew the limits. With a writeback webhook, the outside system can succeed while the Ontology fails. A side effect may not have run when the user sees success. A revert covers object edits only. So one submission cannot be read as all-or-nothing across systems.

A single feature can be found elsewhere: Looker’s Action Hub does write back to external systems. Palantir puts these things into one action type definition. This article did not test other products one by one, and nothing here says whether another platform can reach the same integration.

So to assess any “form submit” mechanism, three questions help. Is the outside system called before or after the object change? When a step fails, which changes are blocked and which are left outside? And what kind of record can you look up afterward?

Next in this series: Without Palantir: What a Contract, a Test and an Approval List Cover.

Frequently asked questions

Do an Action’s edits get written back to the source dataset?

No. User edits are not written back to the dataset backing the object type. To let downstream pipelines read the source data combined with the edits, you can set up materialization; in Object Storage v2, only the latest snapshot is guaranteed to be available. Writing to an external system takes a different route, the webhook.

If a webhook fails, what happens?

It depends on the mode. A writeback-mode webhook runs before object changes, so if it fails nothing else changes. But the external request can succeed while the Ontology change fails. A side-effect-mode webhook runs after objects have changed. Its failure is not shown to the user, and it may run after the user has already seen a success message.

Can an Action be reverted? Does a revert undo the whole action?

A revert only undoes the edits to the object instance. It does not undo side effects such as notifications or webhooks, and it does not call them again in the way the applied action did. Once the object has any later edit, even to a different property, the action can no longer be reverted, and reverts work only on Object Storage v2.

Scope and version

• Every Palantir docs page cited here is the version read in August 2026. Palantir’s pages carry no date, so a page read later cannot be used to infer what it said in August.
• The page name in brackets after a quotation is where the sentence appears in Palantir’s documentation.
• The October 16, 2026 revision changed structure and the wording of qualifications. It did not update the data.