Auto Add Followers to certain department tickets.

[matalaweb]

Departments could have certain users / email addresses that automatically become followers of a ticket, even if they are not the assignee.

[mpge]

I like this idea, but I feel as though this should be implemented via an automation of some sorts.
Similar to the automation system we have in place.

[matalaweb]

That or have an event listener in the host app handle it.

(Still getting used to the fact that this is a extensible package and not an external help desk that I have no control over)

[mpge]

Picked this up. I implemented it as a new add_follower workflow action in the canonical NestJS reference rather than a one-off "department default followers" column. That keeps it general: it works for any trigger/condition, and "followers for a department" falls out as a special case.

How you'd configure the exact ask in this thread (auto-add a user to every ticket in a department):

• Trigger: ticket.created
• Condition: departmentId equals <id>
• Action: add_follower with the user's id (add one action per user you want following)

No host code required — it's all admin-configured Workflow. (If you'd rather keep it in the host app, @matalaweb, the escalated:reply:created / ticket events are still there to hook — but this lets non-developers set it up.)

Under the hood it adds a minimal TicketFollower join table (ticketId, userId, unique so nobody double-follows). A follower is a notification target alongside the assignee and requester. It's also uuid/string-user-key safe, matching the rest of the package.

Reference PR: escalated-dev/escalated-nestjs#61

Deliberately scoped out of that PR (worth their own issues if you want them):

1. Email-address followers — the original idea mentioned plain email addresses, not just host users. Current followers are host user ids only. Adding an email-follower path (and an unsubscribe token) is a clean follow-up.
2. Notification delivery — the table records followers; wiring them into the reply/status-change notification fan-out is the next step to make following actually do something end-user-visible.
3. A manual "Follow" button in the agent ticket UI, reusing the same table.
4. Fan-out of the action to the other backend ports once the reference lands.

Let me know if you'd like me to open tracking issues for any of those, or if you'd prefer a first-class Department.default_follower_ids field in addition to the workflow action for discoverability.

[matalaweb]

@mpge understood. I personally wasn't huge on the automations idea since it's run by a cronjob. While it gets the job done it, the fact that it's decoupled from ticket events just feels strange to me.

Timing could present a small issue as well:

For example if an agent raised a ticket, at say 19:06:04, then ran a custom action (like we released this week) at 19:06:39, the cronjob would not have yet picked up the ticket creation event, thus auto-followers would not be notified if the custom action tirggered something that is notifiable. While it's a small, unlikely edge case, it's something worth considering.

That being said, I think we should also increase visibility of the automations section in docs (add to Installation section) / create an alert in the UI if a cronjob isn't setup / hasn't run recently.

[mpge]

@matalaweb Agreed, I think relying on the automations is fine, but I'll try to build out a system to ensure the automations are also event driven.

Aka a ticket is created -> automation triggered for tickets, etc.
Cronjob should solely be for running outstanding automations or automations which don't necessarily support a hook/event.

[matalaweb]

@mpge great! Let me know if I can be of any help. Sorry I'm fairly limited in my spread of languages/frameworks.

I'm interested in how you've set up your environment to update so many packages consistently and quickly.

[mpge]

@matalaweb I implemented and merged a resolve for this - if you wish to review.