Forum Discussion
I run into this situation often and typically will use either option 2 (duplicate) or 3 (after hours) in your list. It seems like we have limited options as developers since a Pipeline will "self-disable" as soon as an edit is made.
Typically, I'll append "v1" to the original Pipeline, then duplicate it as "v2" and disable the dup. Then, once the new changes are tested, quickly disable v1 and enable v2. There is also a tagging system where you could flag a Pipeline as deprecated. We've also adopted a convention of prepending a lowercase letter "z" to stuff that is soon to be deleted (e.g. zMy Pipeline v1).
One of the drawbacks to this approach is you fragment the run history (Activity Log). Thankfully, I don't refer to it often, but it can be very useful when needed.
Another strategy we'll take it to create a formula checkbox field on the table that triggers the Pipeline. Then, in the Step "A" of the Pipeline include a query condition against the formula checkbox. For example, when "Should Create Some Record" (formula checkbox value) is true, proceed to Step "B."
That way we can adjust Pipelines without editing them by making changes to the checkbox logic at the table level. Of course this wouldn't work in all cases, such as setting values in subsequent Pipeline steps, but it can make the Pipeline a bit nicer to read and avoid some edits.
------------------------------
Brian Seymour
------------------------------