Permissions

Permissions apply to Action types in the following ways:

• Who can view a given Action type?
• Who can edit a given Action type?
• Who can apply an Action type with a given set of parameters?

Apply Action

The ability to apply an Action type depends on the configuration of the object types and link types it is editing. In all cases, 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 the object type only allows edits via Actions, users can make edits for all the objects they can view. For object types and link types allowing edits beyond Actions, the user also needs edit permissions on the writeback dataset if the object type or link type is backed by a dataset. If the object type or link type is backed by a Restricted View, the user needs to pass the edit policy.

Submission criteria

Action submission criteria allow for fine-grained control over who can run an Action. Simple submission criteria can require a specific user ID or group ID and can be combined with information from parameters. For more information see the submission criteria documentation.

Object edits permissions

Object edits can either be locked down so that edits are only allowed via Actions, or reopened so that edits are allowed via Actions, Foundry Forms, direct Object Explorer edits, and API calls. To enforce a consistent security paradigm across many workflows, by default, new object types only allow edits via Actions. Other forms of edits are not recommended for new usage.

For object types that only allow edits via Actions, the user submitting the Action will only need Read access on the objects that are being edited. This means that it is possible for users to create objects that they cannot view.

By contrast, when an object type backed by a dataset can be edited by Actions, Foundry Forms, direct Object Explorer edits, and API calls, the user submitting the Action must have Edit permissions on the writeback datasets of all objects being edited. A user with Edit permissions will be able to view all data in a writeback dataset.

Therefore, setting an object type to be edited by Actions, Foundry Forms, direct Object Explorer edits, and API calls is discouraged since granting Edit permissions simply for object editing may expose more data to a user than is required to complete the Ontology editing workflow.

With either writeback setting, an Action type’s configuration does not display permission settings on affected underlying object types; the person configuring the Action type must ensure that these permissions are correct.

Updating edit permissions on an object type to "Only allow edits via Actions" will not remove historical, non-Actions edits, but they will prevent further edits from Foundry Forms, direct Object Explorer edits, and API calls.

Learn more about writeback permissions.

Side effect permissions

Any user who can set up an Action may configure side effects.

• Webhook side effects are not enabled by default. Additional permissions are required to configure a Webhook plugin in the Data Connection app before it can be used in the Actions setup page. Contact your Palantir representative with any questions about using Webhooks on your Foundry instance.

Submission criteria must pass as normal; if the Action submission criteria fail, then side effects will not be triggered.

Recipients must have access to any object data included in the notifications.

• If a user does not have access to all data included in the notification content, the notification will not be sent to them.
• If there are multiple recipients and some are missing the correct permissions data included in the notification, only the users with sufficient permissions will be notified.
• If notifications fail to send for whatever reason, edits may still succeed.

The user executing the Action must be able to view the users and/or groups that will be receiving a notification.