Admins can create a new Custom Action by navigating to the Actions page and clicking on the “New Action” button.
An Action's basic details provides context to users about who manages the action and how it should be used.
|Name||The name of the action. Users will see this when invoking the action|
|Owner||The team is responsible for maintaining this action. Users invoking an action will be directed to this team in case of error.|
|Description||Additional information about what this action does or how it works. Users will see this information before invoking the action.|
|Mark as draft||
Draft actions are only available to admin users. This option lets you test actions before making them available to other users in your OpsLevel account.
Actions can be scoped to apply to only a subset of the services in your OpsLevel account. For example, an action to provision infrastructure could be set to only apply to services with a tag of prod_enabled: true.
Actions can also be limited to certain sets of users and can have custom input parameters defined.
An Action’s context is where all of this configuration is managed.
Control who has access to this action. Possible values are:
This action will be available to services matching this filter.
Check out the filter docs for more info.
Default: All Services
|Require form submission||
Enables the “input” field allowing you define the action’s user input fields.
Define the input fields that will be presented to the user. These allow users to provide contextual information to the action being invoked.
Inputs are defined using YAML markup, see Configuring Manual Inputs for more information.
An Action's rules define the webhook URL for the action and any information included with the HTTP request.
See the end-to-end example for a sample of Action Rules, including parameterizing a URL with Liquid.
The HTTP method that will be used when the action is invoked.
Supported values: GET, POST, PATCH, PUT and DELETE.
|Webhook URL*||The destination of the HTTP request.|
|Headers*||The JSON representation of the headers to be included in the HTTP request.|
|Payload*||The body of the HTTP request.|
These fields can dynamically insert information from the action’s context via liquid templating.
See the Action Context Schema for the list of fields available and this example for how to use them.
An Action’s response details control what message is displayed to the invoking user after it has finished.
The message displayed to the invoking user after the HTTP request for the action has completed. The message can be conditionally changed based on the fields in the response via liquid templating.
This field can also dynamically insert information from the action’s context into the message body.
See the Action Context Schema for the list of fields available and this example of how to use them.