Workflow_dispatch manual triggers feedback

Great to see you’ve added manual triggers for workflow actions using the workflow_dispatch ( We’ve been using a combination of actionspanel UI and repository_dispatch events from a hosted bot triggered from slack commands to do this previously.


1) Dropdowns for inputs

Would you consider adding a dropdown to the inputs rather than having to type everything? It’s really useful for avoiding typos? Right now we’re using a slack workflow to automate this as they have dropdown support:


2) Multiple triggers per workflow

It’s awkward to have just 1 trigger per workflow. Often we use the same workflow with multiple use cases with different parameter sets to do different things.

This is important because github actions doesn’t have inheritance, so copy/pasting the same workflow multiple times becomes a maintenence nightmare, so highly generic / parameterised workflows are common.

For example, we have a github action to put a message on an AWS SQS queue for processing, and we have 3 different queues to integrate with. Ideally I would like to define:
a) Workflow 1: trigger SQS workflow with queuename=xyz, payload={input}
a) Workflow 2: trigger SQS workflow with queuename=abc, payload={input}

This is how the current actionspanel design works - you can define multiple workflow triggers.

3) Populate inputs from querystring

Please allow populating inputs from querystring parameters from an external URL. This allows us to link populated forms to other developers for them to trigger so they don’t have to type everything themselves, and we can save specific parameter sets simply using a URL.


This also provides an easy way to automate integration across services like slack - slack workflow UI can easily generate a URL to click on then github authenticates, populates the form and triggers the action when clicked.



Thank you for the feedback.

We do have plans to add more options for inputs in the future, however, we had to constrain the feature set to fit around some other work we are doing.

We have plans to implement inheritance and other reuse models for actions workflows, so we didn’t want to overcomplicate the manual triggering scenario with many different options.

I will add the query string option to our backlog to consider.


Having the option to use dropdowns for inputs or boolean inputs with checkbox will be useful in some scenarios.

In a project we are using manual triggers to publish on demand some artifacts. Having stage or prod will simplify things. Having one workflow per environment is doable but would require some inheritance and share to avoid duplication.

One issue I noticed is that when triggering a manual workflow, the UI requires a full refresh to show the newly created execution instance.

Thanks for shipping manual triggers UI, it’s great!


And few more feedbacks to add:


  1. When I have triggered the run with input parameters. I can’t see it in history like what parameters I used. Or Like My last jib was for Test or Prod.
  2. Dropdown/checkbox options for input parameter

Nice to have:

  1. Average time taken by previous jobs and then showing some progress bar.