The default behaviour for lightning instance installs renders concurrency for workflows that use a sync-mode webhook trigger inert, but right now it the UI makes it look like you can set concurrency for those workflows.
We should disable the workflow concurrency input when sync mode is enabled for that workflow trigger, or at least warn that given the current worker settings (hard to know, eh?) whatever you type into this box will be completely ignored!
A little red text, or a warning icon with hover info explaining why you can’t set or change the workflow concurrency for this particular workflow feels like a must.
Note: that in a perfect world, the app might know if workers with fast-lanes are currently connected and only disable the setting if fast-lanes are turned on. It also might communicate the uncertainty, and say "sure, change this setting all you want, but in the future if someone turns on or off fast-lanes, whether or not this setting is respected will change"
The default behaviour for lightning instance installs renders concurrency for workflows that use a sync-mode webhook trigger inert, but right now it the UI makes it look like you can set concurrency for those workflows.
We should disable the workflow concurrency input when sync mode is enabled for that workflow trigger, or at least warn that given the current worker settings (hard to know, eh?) whatever you type into this box will be completely ignored!
A little red text, or a warning icon with hover info explaining why you can’t set or change the workflow concurrency for this particular workflow feels like a must.
Note: that in a perfect world, the app might know if workers with fast-lanes are currently connected and only disable the setting if fast-lanes are turned on. It also might communicate the uncertainty, and say "sure, change this setting all you want, but in the future if someone turns on or off fast-lanes, whether or not this setting is respected will change"