The Palantir documentation describes how to set up a third-party application for running automations and why you might want to do so here.
It advises setting the application scope to Unrestricted for the initial setup, which for some production use cases might not be palatable. The docs do suggest you can change this later;
You can adjust this after creating the application one [sic] the OAuth & restrictions page.
But if you do the next time you update the automation you will get an error.
Monitor Registry: Edit Automation Metadata Permission Denied For Third Party App Owner
The issue is that the 3rd-party user owns the automation, and it can only make changes to the automation if it has the permissions to do so. Since the permission needed to update automations is hidden from the Oauth & restrictions menu, the only you can make edits is to temporarily make the user unrestricted. So the workflow becomes:
-
Follow the docs to create the automation with unrestricted scope
-
Restrict the scope of your application (see guidance below)
-
When you need to make changes to your automation
3.a Change scope back to Unrestricted
3.b Update and save the changes to the automation
3.c Revert your application back to restricted scope
For most automations you can probably get by with the following OAuth scope:
-
Ontology SDK - Select the action types you’re running, accept the defaults
-
Platform SDK -
ontology:readandontology:write -
Project scope - The project containing your automation(s) (the user needs to have Editor on this project, per the docs)
-
Marking scope - As desired
This is a little bit painful, it would be nice if there was a way to work around this to make it easy to configure robust application scopes for 3rd-party accounts.