Create a new version, trigger is not copied -->does it work as designed?

Options
Ye_939471
Ye_939471 Posts: 61
in Questions

Hello, dear team:
After creating a new version, the trigger is not copied from published version.
I have to re-build a new trigger.
If I want to build the same trigger from the published version, catalytic reports error during saving the trigger.
This is somehow a trouble.
For example:
When the trigger is a web form, I need to update the web form link for a new version.
When the trigger is a email, I need to update the email address for a new version.
As a result, I need to inform the users that the web form link or catalytic mail address is changed...

Does this really work as design?
Is it possible to use one trigger for all versions of a workflow?

Tagged:

Best Answer

  • Chuck_146211
    Chuck_146211 Posts: 36 admin
    Answer ✓
    Options

    Hello @Ye_939471,

    This functionality is working as intended. When creating a new (draft) version of a workflow, the triggers are not included in the draft. This is to avoid having duplicate triggers as the previous version is still published.

    Once you publish the draft version, the triggers will carry over to this newly-published version.

    You can find more examples of how this works in our help article on version control.

Answers

  • Anna_272419
    Anna_272419 Posts: 42
    Options

    @Chuck_146211 Thank you for the feedback, I was observing the same situation re:triggers as the OP.

    This design is problematic when the trigger is a webform. We've experienced difficulties testing webforms in draft environment and then publishing the new draft webforms to the published bot. Seems like the process could be smoother.

  • Ye_939471
    Ye_939471 Posts: 61
    Options

    Hello @Chuck_146211 ,

    Yes, the trigger feature is added to the new version after published.
    However it is still inconvenient during testing the new version before publishing, since there is no trigger copied from previous version.
    I have to create a trigger.

    Then awkward situation is when I forgot to delete the testing trigger and published the version, the new published version would have 2 triggers....

  • Chuck_146211
    Chuck_146211 Posts: 36 admin
    Options

    Thank you both for this feedback, @Anna_272419 and @Ye_939471. I understand where you're coming from as I've been in similar situations when building and my workflow relies heavily on the fields output from a trigger.

    Here are a couple methods I've found helpful when testing draft versions.

    Web form trigger version testing
    When versioning a workflow with web form triggers, I find it best to run test instances in "test" mode.

    The Form Fields from the original workflow will carry over to the draft version and will behave the same way as they would on the web form trigger's form page. In the screenshot below, I have a draft version of a workflow that normally runs from a web form trigger.

    When you start an instance in "Test" mode, a window will pop up that contains the form fields that would be displayed on the web form trigger. You can fill out these fields the same way you would from the web form's trigger page and your test instance will start using that data.

    Email trigger version testing
    If I need fields from an email trigger (the {{html}} field, for example), I'll usually create a new email trigger on the draft version with an email address that will not get emailed by mistake/on accident from others internally or externally (e.g. myuniquenamefortesting@____.pushbot.com).

    This saves me time in the long-run because I don't have to go through every action that references the trigger fields and update those to a temporary testing field.

    If I forget to remove the trigger from the draft version, I know that instances on the draft version will not be started in the future because I used trigger email address that I did not distribute to others.

Categories