After you create an HTTP trigger or custom step, you might want to come back later and change things up. Of course, if the step
We don't want you to break flows you might not know about, so there are three types of changes:
- Non-breaking changes.
- Changes that impact the results of the step but don't technically break it. We let you make these changes, but we warn you which flows it might impact.
- Breaking changes that we stop you from making until you've removed the step from the flows it's used in.
We also don't let you delete a custom step that's still used in a flow because that's the ultimate breaking change.
If you want to make changes to a deployed step that's used in a flow, you can also create a new version of the step linked to the current version. This lets you make more significant changes to the step and set the state to In Development so you don't let the changes out in the wild until they're ready. Or you can copy a step to create a completely new step using the existing one as a template.
The process of editing a step is similar to creating the step in the first place. To edit a step, you need edit permissions for the step.
- To edit a step, locate the step or HTTP trigger in the palette, click the gear icon next it, and select Edit.
- To edit a version of the step other than the default, click Show versions in the edit step dialog and select the version you want to edit.
- Before you start editing, check to see if there is a Usage tab. This tab appears when the step is used in a flow, and lets you see where the step is used so you know what flows your change might impact and what changes you might not be able to make.
- Make your changes.
If you're prevented from making a change, it means that change could break an existing flow. There are a few ways you can still make the change:
- Use the Usage tab to find where the step is used, remove it from the flow, and then come back and make the change.
- Create a new version of the step, leaving the existing version intact. You can then look at the Usage tab for the previous version and switch the version used in those flows, if appropriate. Keep in mind that if you make a breaking change, it might cause flows to break when users update the flow to use the new version.
- Create a new step by copying this one, then come back to this step and see where it's used on the Usage tab, replacing those instances with the new step, if appropriate.
- If you've made changes to settings that are used in the script (for example, the endpoint or inputs), make sure you update the script.
- Click Save when you're done making your changes.
The following table lists which changes are allowed when a
|Endpoint type||Yes*||You can change the current endpoint type to Any (but not to any other type).|
|Endpoint label||Yes*||The script is not updated automatically, so make sure you update any references to the endpoint.|
|Endpoint requirement removed||Yes*||You can remove an endpoint but this may break flows where the step is used.|
|Endpoint requirement added||No||Not allowed since any steps already in use would not have the endpoint configured.|
|Add an input||Yes*||You can add a non-required input anytime, but you can't add a required input if the step is in use, since existing steps might not have this input configured.|
|Add/update a default value for an input||Yes||Existing steps won't be updated to use the default value.|
|Add/update help text||Yes||n/a|
|Rename an input||Yes*||The script is not updated automatically, so make sure to update any references to the input.|
|Remove an input||Yes*||The script is not updated automatically, so make sure to update it to remove the input.|
|Make an input required||No||This is not allowed since it would break existing instances of the step.|
|Change the minimum and maximum length||Yes*||You can decrease the minimum or increase the maximum length for an input, but you can't increase the minimum or decrease the maximum since this would break existing instances of the step.|
|Add a new output||Yes||n/a|
|Rename an output||No||You can't rename an output since this could break flows where the step is used.|
|Remove an output||No||You can't remove an output since this could break flows where the step is used.|
|Edit the script||Yes*||This is allowed because there are countless reasons why you might want or need to edit your script. However, we recommend you check the Usage tab first just to double-check that you want the change to apply everywhere the step is used.|
|Version label and details||Yes||—|
|Current State||Yes*||You can set an In Development step to Deployed, but can't set a Deployed step back to In Development if it's used in a flow.|
|Run Location||No||This is not allowed since it would break flows that use the step.|
Deleting custom steps or HTTP triggers from a flow is the same as deleting any other step: hover over the step and click the delete icon (the trash can). To delete the step from the palette so it cannot be used, you first need to make sure it is not used in any flows.
- Locate the step in the palette, click the gear icon beside it, and select Delete.
- If the step is used somewhere, a message displays where it is in use so you can find those instances and remove them without breaking your flows.
- When the step is not used in any flows, a message prompts you to confirm that you want to delete the step. Click Delete to permanently remove the custom step.