• Documentation
    • Search documentation
    karat

    +

    K

    API Reference ↗
    Data connectivity & integrationRecipesCore concepts

    Core concepts

    The Recipes application is in a steady state and is no longer being updated. We recommend exploring other applications and features to monitor conditions in Foundry:

    • Automations: Create automations that run on top of your data and track individual searches and objects, triggering notifications or other actions when certain conditions are met.
    • Foundry Rules: Create logic-based rules to apply to datasets, objects, and time series that trigger alerts when certain conditions are met.
    • Monitoring at scale: Use check groups or monitoring views to view metric updates of Foundry resources, including datasets, agents, schedules, objects, and link types.
    • Workshop: Build an alert inbox or other notification workflow to configure actions that will trigger when certain conditions are met.

    Contact Palantir support if you have questions regarding the appropriate workflows to implement for your monitoring use case.

    Before using Recipes, we recommend learning more about the core concepts that define the creation and use of recipes in Foundry: expiration, run history, and permissions.

    Expiration

    Recipes take computational resources to continue to operate. To ensure that unused recipes do not take up resources, we require recipes to expire. When recipes expire, they are not deleted. Expired recipes simply do not continue monitoring for the condition of interest, which means all recipients of that recipe's notification will no longer be notified. The author will be notified at some intervals before a recipe is set to expire and can choose to extend the expiration at any time if they want it to continue running. If they forget to do so and the recipe expires, they can still choose to resume and extend the recipe.

    Learn more about changing recipe expiration.

    Run history

    Based on your schedule, your recipe will run either on a time-based schedule (for example, every 3 hours or every Monday at 9 a.m.) or an event-based schedule (when a dataset updates or when a new object is detected).

    Each time the recipe runs, its run history will record one of the following run statuses:

    • success with exceptions: The recipe ran successfully and notified all recipients who had access to the resource and did not mute the recipe. This status may occur if some recipients lacked access to the resource and did not receive a notification. In the case of a report recipe, success with exceptions can also occur if exporting the report failed for some recipients and they received a link instead. Learn more about recipe permissions and security below.
    • success: The recipe ran successfully and notified everyone who did not mute the recipe.
    • skipped: The recipe was successfully triggered but did not send any notifications. This could occur either because all recipients had muted the recipe or because the condition it was checking was not true.
    • failed: The recipe did not run successfully and encountered an error while running. More details about this error can be seen by expanding the recipe history for this run.

    An author will receive notifications for failures and successes with exceptions. Learn more about configuring your notification preferences.

    Privacy, permissions, and sharing

    Recipes inherit permissions from the resource it monitors. This means that anyone who can view the resource can view the recipe, anyone who owns the resource can edit the recipe, and so on.

    While recipes can send data out via email to other users, permissions ensure that only the users that have access to the data will actually receive that data in their email.

    Permissions summary

    Definitions

    • Author/Owner: The user who created the recipe.
    • Recipient: The recipient of the triggered email/notification of the recipe.
    • Monitored resource: The actual file the recipe is monitoring for the change of interest (dataset, report, Quiver analysis, etc).

    The table below shows the permissions necessary for users to perform certain actions in Recipes:

    Action Authorized users
    View the recipe The author or anyone with `Viewer` access to the monitored resource
    Modify and manage the recipe The author or anyone with `Owner` access to the monitored resource
    Receive emails/notifications from the recipe Recipients with `Viewer` access on the monitored resource (1.)

    If the recipient does not have access to a report, they will still receive the notification. However, they will receive a link to the report which will direct them to request access.

    If a user tries to add a recipient to their recipe who does not have access to the underlying resources, the recipient will be able to see the recipe but not the resources. They will receive the email/notification, but they will not be able to open the linked resource, and the email/notification will not contain any attachments. To allow all recipients to receive emails/notifications, make sure they have at least Viewer access to the recipe resources.