Manage and deploy triggers for existing slack app installed in client's workspace.

[harshbhardwaj29]

Question

I have a use case to create new triggers for invoking workflows. I understand workflows can bundled into JSON/YAML into slack app workspace.

1. How can we create and manage triggers to invoke those workflows once added to the app manifest.
2. Is there any other way apart from CLI to manage triggers.( please refer documents if available).
3. Do i need to re-install my slack app into client workspace if added workflow

Context

I did not found any documents managing and creating triggers at scale in production like slack apps.

Environment

@slack/deno-slack-sdk": "^2.10.0"

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[zimeg]

Hey @harshbhardwaj29 👋 You're right that workflows are included in the app manifest, but triggers are tricky and act as separate entities from this and have to be created after installing the app.

1. Triggers can be created a few ways - either using a trigger definition file or during runtime. The way to invoke a trigger depends on the type of trigger too: link triggers can be started by clicking a link in Slack while you'll have to wait on a scheduled trigger.
2. At this time the endpoints to manage triggers aren't public but I'll check on this. For now the CLI offers commands to create, delete, list, and update trigger details, as well as collecting info or change edit access.
3. Adding a new workflow to your manifest doesn't require you reinstall the app, but it will require you update the manifest. The CLI currently handles this by reinstalling the app, but if your scopes aren't changing an update should work fine. Existing triggers will also continue to work if the inputs of a trigger's workflow doesn't change.

Hopefully this is helpful, but please follow up with any other questions! I hope to return with an update on these endpoints soon. And I'm also curious if you can share more about the production scale you're facing and how you'd ideally like to manage your triggers? It's really helpful feedback for us to make improvements in this area!

[harshbhardwaj29]

@zimeg The slack app i have is mostly configuration based, no code structure exists like workflows, trigger folders, i have created workflows and embed into app manifest, but the concern are the trigger creation and deployment, with folder structure exists in docs, it is possible to manage trigger using CLI but there is no mentions for creating trigger without the code structure, any points on that.

[zimeg]

Would creating triggers from only JSON definitions be suitable for you? These would still be separate from your manifest but wouldn't act as active code 🤔

If so, a link trigger can be defined as so:

{
  "type": "shortcut",
  "name": "Begin an automated process",
  "description": "A sample trigger",
  "workflow": "#/workflows/sample_workflow",
  "inputs": {
    "channel": {
      "value": "{{data.channel_id}}"
    }
  }
}

And event triggers like so:

{
  "type": "event",
  "name": "Respond to a rocket reaction",
  "description": "responds to a specific reactji",
  "workflow": "#/workflows/sample_workflow",
  "event": {
    "event_type": "slack#/events/reaction_added",
    "channel_ids": [
      "C0123456789"
    ],
    "filter": {
      "version": 1,
      "root": {
        "statement": "{{data.reaction}} == rocket"
      }
    }
  },
  "inputs": {
    "channel": {
      "value": "C0123456789"
    }
  }
}

Edit: The CLI can then manage triggers using these files with slack trigger create --trigger-def=<file>

[harshbhardwaj29]

@zimeg what should be the ideal place to have these triggers, so it can pull mapping of workflows in app manifest like
"workflow": "#/workflows/sample_workflow"

[zimeg]

@harshbhardwaj29 as long as your manifest includes the #/workflows/sample_workflow these trigger definitions can exist anywhere!

I might suggest a triggers directory to keep things tidy. Updating values of the trigger definition is possible, but would require a bit of JSON processing at some point to override the workflow value with something from your manifest. Once the trigger endpoints are public, currently a WIP, this might become easier as changes could happen during runtime.