Today, blocks with dependencies are not usable in custom automation builder. If they use a custom field with a dependency, the action/trigger editor disables publishing the block. However, built-in fields with dependencies (status column value for example) don’t disable publishing (event though they don’t appear to work correct in the builder) - which means non-functional blocks can get published.
I propose a revision to blocks/dependencies which will help solve this limitation.
Move the dependency configuration to the workflow block, or at least part of it. Allow us specify the following for each field dependency when the field is added to a block:
- source
** current block (default for trigger blocks) - self explanatory, when selected will then present field keys from the block being edited.
** trigger output (action blocks only [obvs]) - present the field names for any fields of the correct type across built in-triggers.
** recipe configuration - configure this fields dependencies with the recipe. Pretty much what we have today. - field
** When “current block” is selected - present the list of compatible fields from the current block.
**trigger output - three modes
+++Automatic mode - selects the only field on the trigger that matches the type (Board for example)
+++Manual mode - select an ID from the list of IDs present on built-in triggers that match the correct type.
+++Custom mode - direct entry of a field name.
** When “recipe configuration” is selected the field input is disabled.
When “recipe configuration” is chosen, that dependency would then be configured during recipe configuration. The “recipe configuration” selection would be a determining factor as to if the block can be published or not.
Here are details on the “trigger output” options.
- Automatic mode - custom automation builder would filter out the action block if it has field that depends on a field type that doesn’t exist on the trigger, or the trigger has multiple fields of the type it depends on.
- Manual mode - custom automation builder would filter out the action block if it depends on a field id not present on the trigger.
- Custom mode - same as manual mode. This mode could permit dependencies on triggers with multiple outputs of the same type. The same concept could be applied to input fields, to permit actions with multiple fields of the same type referencing trigger outputs (would greatly limit compatibility but useful with custom trigger+action recipes to then enable generic actions to be used alongside)
Any previously created blocks would be treated as if “recipe configuration” was selected (and upon opening to edit those blocks, be converted to the new block type with all dependencies listed as “recipe configuration” since this is identical to the current situation.
