Show us your Workflows

Continuing the discussion from A preview of the new Workflows feature:

I am pretty pumped about the launch of Workflows. I dreamed about this feature when I was an active community manager looking for ways to automate repetitive tactical community processes.

I’m super curious to see what kinds of things you are using Workflows for (or will do, now that you know about them!).

I’ll start—but I will concede that I had to delegate the actual building of it to @zogstrip and @chapoi because I don’t have the skillz.

Weekly Update Reminder Workflow
The only thing we mandate of our team is a once weekly check-in so that we know they are healthy and happy. Some people don’t do it (for a variety of reasons) and it wastes time and energy having to chase them up so we have a new solution.

This workflow checks for an update and serves progressively worse CSS to them, the longer they leave it.

It’s amazing how effective it is!

10 לייקים

Love the CSS :laughing:! Could you share it if possible?

2 לייקים

Please don’t tell me you… want the ugliest theme I’ve ever made? :sweat_smile:

3 לייקים

I do actually :laughing: . Looks very… creative :eyes: .

2 לייקים

It really is incredible. I know, because in trying to test something unrelated I inadvertantly put myself in Group 4 and had to try and debug the problem while everything on the screen kept floating away. :laughing: @zogstrip was very patient.

2 לייקים

it’s not super super obvious from the workflow overview, so here’s how it works

part 1 - yellow box

  • for every posts created/edited in the #updates category, we check whether it’s coming from the author of the topic
  • if it’s not from the op, we “bail out”
  • if it’s from the op, we run it through an llm classifier that returns some json indicating whether the post is an actual weekly update (we don’t require a specific format) and not a random reply to another post
  • then we store that classification result in a data table
  • if the post is classified as a weekly update, we immediately remove the user from all the “late” groups (the green box)

part 2 - blue box

  • every day, at 6am utc, we run a data explorer query that combines all the leaves, holidays, and “latest weekly update” to put people in one of the four “late” groups

part 3 - not shown in the workflow

  • we have a custom theme component[1] that checks whether the current user is in one of the “late” groups and apply more… annoyance :sweat_smile:

  1. applied to all our themes ↩︎

5 לייקים

We require some tags to be used but members have a habit of posting in incorrect categories which means far too much time moving topics to the right place.

A very basic workflow that runs on topic creation checks the tags in use and then automatically changes the category.

Something so simple has helped maintain some structure while using zero effort to do so.

2 לייקים

Following up on a post I made in the original workflows topic. I have figured out how to make it do what I want it to do. This is all a test of course, but here is what it does:

This is a re-engagement system that uses AI to hopefully spark discussion and boost re-engagement at times when the site is slow.

Phase A: Locate and Summarize

Locate posts that are older than 30 days and are some mix of the following:

-Popular topics that haven’t had a post in a while.
-Topics that are getting a lot of views, but haven’t had a reply in a while.
-Topics that had some activity in the last year, but then stopped.

Once it finds one, it initiates the Discourse ‘AI Summary’ agent. Have the AI agent write a summary. It does this by POSTing a http request to the summary API endpoint. Once the summary is done, it saves the existence of the workflow into a data table.

(This runs once an hour, but potentially more often).

Phase B: Evaluate Summary for Follow Up

Another scheduled workflow runs independently on its own schedule. It checks the data table for rows that have been summarized, but not evaluated. It grabs one topic from the data table and then gets the 5-10 most recent posts on that topic.

It goes into an AI agent that handles triage. It makes a determination. Is this a topic that should be revived? If so, how? It decided if the topic should be bumped, or if a post should be made that re-engages with the topic: asks a question, asks a follow up or nothing at all.

It updates the data table with the decision.

(This should run about as often as Phase A, you could also trigger it from or combine it with Phase A.)

Phase C: Re-Engage with Topic

Another scheduled workflow runs on its own schedule, not as frequently. It’s first step is to check and see how active the forum has been lately. It does that by checking how many posts have been made on average per hour, for the last 3 hours. It then takes the average of how busy the forum has been for 3 hour periods, on the same day and time over the last 2 months. If the site isn’t as busy as it normally would be at the same time on the same day, it will say ‘we can do a re-engagement now’.

It then grabs up to 10 available re-engagement opportunities. It sends to an AI agent and asks to pull out the strongest candidate for a re-engagement out of the list. The AI decides and returns a topic_id. The classifier in Phase B decided between 3 options: Bump topic, post follow up, do nothing.

The workflow will do a bump unless the follow up is designated. If destined for follow up, it will take the topic id and grab the latest posts from that topic. It will hand it over to an AI agent who will determine what the best response would be to re-engage with the topic. It has guardrails to ensure a very basic reply, that is still on topic and doesn’t give recommendations or provide commentary. It mainly just asks for an update, asks if the original poster has an update on something that happened.. etc. It posts the reply and then updates the data table with the completed at date.

Hopefully I didn’t just duplicate some hidden Discourse feature that I didn’t know about! It took some trial and error, but I got it done.

5 לייקים

Here are a few for generating weekly reports that we’re using keep our team informed of various activity on meta. Each has a topic in the staff category where the results are posted to.

I think they should be mostly generic, if you want to try them out on your own site. You should just have to change the topic ID where the results get shared in the final node to a topic in your own staff category.

(You may need to manually edit before you import. I manually overwrote them as TOPIC_ID after exporting to help avoid accidents)

weekly moderation report
file: weekly-moderation-report.json (21.4 KB)

  • Includes tables listing:
    • moderation summary (counts of various moderation acts)
    • number of flags handled by different users
    • number of flags reported by different users
    • list of flagged posts w/ associated metadata
    • warnings issued
    • user notes added

weekly site settings report
file: weekly-site-settings-report.json (3.3 KB)

  • Includes table listing site setting changed
    • setting name
    • who changed it and when
    • old value, new value

weekly trust level report
file: weekly-trust-level-report.json (9.8 KB)

  • Includes tables listing:
    • summary (number of users proposted to each trust level in past week)
    • list of users who gained trust level 2 or 3
6 לייקים