Is a Community Workflow template planned? I think it can add a lot of value to this fantastic implementation.
I do not know the technical limitations, but I think that Discourse Discovery can enable/disable this functionality and re-use the connection to the Discourse ecosystem.
Ok I did not see it probably because I have to update, thanks.
[Edit] Everything fine after update, thanks so much for that manual Bump 
Hi @j.jaffeux , when using the trigger “new user”, I wish the following action happens only if that new user account has been activated (to exclude the bots registring new users), do I have to use the “approved” status for that as a filter? Thanks.
And if my above assumption is correct, how do I specify the TRUE value? As “True” or “T” ? Thanks?
It seems to have worked after all! I’m really happy about this feature.
Instead of drag/drop user.approved, stay in plain mode and select user.approved in the list and you should see this:
Is it possible to have
trigger: a specific user posting via email replies in a particular category
action: the event of the topic a specific user posting via email replied to is automatically closed - similarly to
No we are missing few details for this
Thanks - do you mean there are a few details/data points still missing from Workflows to support this use case?
Thanks I did, but the filter user.approved does not seems to filter users that registered and confirmed their account.
I’ve been trying to get something going for hours using the workflows. I can’t seem to get the AI to work without it throwing an error. I may change the AI model and then try again.
What I am trying to accomplish is something like this: (and very relevant to the recent discussion!)
Basically just trying to make a workflow that tries to get some random re-engagement on posts that are stale, but may need a follow up posted.
Anyone have any ideas? I could get the posts using data explorer and could get a summary from the AI. I couldn’t get data tables working and didn’t make it to the auto post stage. But I got somewhat close.
My thought was splitting in into several workflows:
Not sure if I have this figured out with how to use it, but this plugin has a lot of potential!
EDIT: I got this working and posted it on this topic:
it’s in the output where you can define json data yourself
@j.jaffeux Following up on my question above, I’ve opened a PR which adds an Event action to Workflows:
It adds:
The action takes a topic ID, resolves the event from the topic’s first post, and updates the event through the normal post-edit/Event synchronisation path.
I’ve tested the original direction of the use case with:
Post created → Event / Close event
using Input → topic.id.
A reply to the event topic then closes the event while leaving the topic itself open, and the change appears live in the UI.
The PR includes unit/integration coverage, and the full discourse-events suite passed with 1124 examples / 0 failures.
This addresses the Event action side of the use case I mentioned above. The user/category/email-origin conditions can then be handled separately by the workflow trigger/conditions.
Any tips on auto-tagging responses from an AI agent? I’m trying the following workflow, but it’s not catching responses from the agent user.
FWIW, this is a hidden tag, but the agent is in a group that has visibility to it.
{
"id": "6",
"name": "My workflow",
"nodes": [
{
"id": "a8490306-e7e7-42e4-b909-851f3c4fbcba",
"type": "trigger:topic_created",
"typeVersion": "1.0",
"name": "When a new personal message is created",
"parameters": {
"topic_type": "personal_messages"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 178.6210678807947,
"y": -18.94519916824343
}
},
{
"id": "a80813a3-35cf-414e-98b8-9892f3eab496",
"type": "condition:filter",
"typeVersion": "1.0",
"name": "Keep PMs from Navigator",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "sender_is_navigator",
"operator": {
"type": "string",
"operation": "equals",
"singleValue": false
},
"leftValue": "={{ $json.post.username }}",
"rightValue": "Navigator"
}
]
},
"credentials": {},
"webhookId": null,
"position": {
"x": 290.515625,
"y": -18.281249999999993
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
},
{
"id": "acfcf305-1a04-4d2e-876c-48b015dc038c",
"type": "action:topic_tags",
"typeVersion": "1.0",
"name": "Add onboarding-initiated tag",
"parameters": {
"topic_id": "={{ $json.topic.id }}",
"operation": "add",
"tag_names": "onboarding-initiated",
"actor_username": "Navigator"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 513.1770833333333,
"y": -27.32031249999998
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
}
],
"connections": {
"Keep PMs from Navigator": {
"main": [
[
{
"node": "Add onboarding-initiated tag",
"type": "main",
"index": 0
}
]
]
},
"When a new personal message is created": {
"main": [
[
{
"node": "Keep PMs from Navigator",
"type": "main",
"index": 0
}
]
]
}
},
"settings": {},
"staticData": {},
"pinData": {},
"versionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"activeVersionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"versionCounter": 31
}
I would really love an automatic action when creating an event: for the author to be automatically registered by default. This would accommodate all scenarios, and especially my own use case! 
we have a node for event coming next week
Yes, I think this could fit naturally into the same Event area of Workflows.
In my current PR, FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub , I’ve added an Event section in the workflow builder. In the screenshot in the PR description, opening that Event menu currently gives two operations:
Those are deliberately the only two operations in that PR because that is the scope of the change I’m trying to get reviewed.
Your use case could potentially add another operation to that same Event menu, something along the lines of Set attendance / Add attendee. A workflow could then use the event author as the user and set their attendance to Going when the event is created.
I think it would be better implemented generically - choosing the user and attendance state - rather than having a special-case action only for “automatically register the author”.
I’ll have a look at this as a follow-up, probably as a separate PR so the current Open/Close Event PR stays focused.
I hadn’t seen your reply before I posted mine above.
Since you mentioned an Event node is coming next week, I’ll also test my current PR locally against the other open discourse-events / Workflows PR branches that touch the same area, rather than relying only on CI against main.
If I find any actual overlap or conflict, I’ll report it on the relevant GitHub PR rather than cluttering this topic.
I think this is because this user needs to be in pm_tags_allowed_for_groups, arguably the error could be better… Will improve it.
EDIT: will be improved by FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub