Strategy for enabling quick Flow Trigger or Action replacement

Every flow begins with a trigger.  In some cases, the business needs may change, which will require you to change the type of trigger being used.  If there are any references being made to dynamic content coming from the trigger, then you will notice as shown in Figure 1 that the Delete option for the trigger has disabled.  This is a mechanism used by Flow to ensure that you are not referencing dynamic content that is not available (NOTE:  it's possible to use expressions that refer to some dynamic data, which would not be checked by Flow, but would result in run-time errors.  Those examples are beyond the scope of this article).

Figure 1:  Trigger Delete option is disabled when dynamic content is reference in actions

The way to overcome this limitation is by storing the dynamic content you are referencing from the trigger in variables or other actions downstream.  Figure 2 shows an example, where the SharePoint list item ID is stored in a variable called Item ID.  Actions that need to refer to the trigger's Item ID can simply refer to the variable instead.

Figure 2:  Variable being used to store dynamic content from the trigger

Now, if you need to delete the trigger, simply delete its reference used in the Item ID variable.  All other actions downstream of the variable definition that refer to it will not be affected by this change.  As you see in Figure 3, the Delete option will now be enabled again on the trigger.  

Figure 3:  Removing reference to trigger dynamic content enables the deletion of the trigger

Once you delete the trigger, you will be able to select a new one a shown in Figure 4.

Figure 4:  Selection of a new trigger

In some cases, you may want to reference several dynamic content elements from the trigger.  Though it's possible to use one variable for each, it can get a bit more overwhelming to create so many variables.  Instead, you can use the Parse action that will store the output of the trigger.  To properly reference the fields within the Parse action, you need to define the schema.  One simple way to do this is to run the Flow without a schema (by setting the schema to {} ) and looking at the Body of the Parse function, as shown in Figure 5.

Figure 5:  Getting the schema of the trigger body

Save the body text and go back to editing the Flow.  Now, you can select the Use sample payload to generate schema for the Parse action to generate the schema.  Make sure that all fields are properly filled in the sample data; otherwise Parse will ignore them.

You can now reference the parameters from the Parse action schema in your downstream actions as depicted in Figure 6.  Keep in mind though that as you switch triggers, the type of data and variable names may change and you may need to modify the data to adjust it.  For example, a SharePoint list item identifier is stored in a field called ID.  If you work with a Dynamics 365 record, the identifier of the record is ItemInternalId.

Figure 6:  Referencing Parse parameters in downstream actions

You can even apply a similar approach to various actions throughout your Flow, where you may need to swap it out for another action.