To trebuchet, or not to trebuchet? 🤔

This question is mainly directed at @Lucas_Pires and/or @Robert_Petitto, but if anyone else has any advice I’ll be all ears :slight_smile:

A couple of months ago, I built a prototype for doing Global Announcements. I did it because it was something I knew I’d be needing sooner or later for one of my apps. I now need to implement it, and I’ve been thinking over my approach for a week or two, and procrastinating, mainly because I’m not really sure that the approach I have in mind is sound. So I guess I’m seeking a bit of validation.

From my earlier post, my requirements are:

  1. An Administrator can create an announcement and target it at a specific group of users
  2. When a user opens the app, any new announcements will be front and centre on their dashboard
  3. The user can view the announcement and mark it as read
  4. Administrators can track how many users have read each announcement, and which users

I need to expand a little on the first requirement…
Users of this app can be categorised in two ways:

  • By Division. Each user belongs to a division, and divisions have names such as Sales, Operations, Marketing, etc.
  • By Employee Type. This is a little more obscure, but the important point is that every user will have an employee type

Currently, we have 7 employee types and 12 divisions - but those numbers could change. And this is where the challenge comes in (and where I think I need to use an extra bit of trebuchet magic).

When an administrator creates an announcement, he needs to be able to target that announcement at any combination of employee type and/or division. For example:

  • Announcement A
    • Goes to Sales, Marketing and all employee types in those two divisions
  • Announcement B
    • Goes to all divisions, but only employee types X, Y & Z within each division
  • Announcement C
    • Goes to all divisions and all employee types (everyone)

In coming up with a solution, I have two main goals:

  1. Each Announcement should only occupy a single row, including the tracking of which users have read the announcement (ie. trebuchet to the rescue)
  2. The solution should be easy(ish) to maintain, and should be easily extendable in the case that the number of Divisions and/or Employee Types changes in the future.

A simple brute force approach would be to just add a bunch of boolean columns to my Announcements table - one for each division, and one for each employee type - and be done with it. But I really don’t like that, and I think it would be much more elegant (and way cooler :rofl:) to store the target employee type and division in a single column each, using trebuchet.

But I’m a bit worried that once I start down this path I could end up tying myself in knots trying to implement it and wind up with a huge mess. In particular, I’m struggling to visualise how I would handle “add/remove all items in the list” using trebuchet.

So, my question: is this a good use case for trebuchet, or should I just take the easy way out? :thinking:

PS. If it is a good use case for trebuchet, any implementation tips would be extremely welcome :smiley:

1 Like

Would it be easier to build out joined lists of user IDs based on selected divisions/types then write that joined list to a column in the announcement row? So rather than trying to save a combination of divisions/types, you are just building the list of individual users.

The one question I would have though, is what should happen if a new employee joins a division. Are they supposed to see all of the announcements that were issued prior to being hired, or are they only supposed to see announcements after being hired?


Yep, simple relation to a join column of roles

This was going to be my question as well…are previous announcements available to new hires?…much trickier.

Trebuchet is definitely possible here.

I agree with Jeff that joined lists by division could be an efficient way to add groups of users via Trebuchet. Might not be able to remove by groups, but a clear all button would work nicely if the admin needs to start over.


hmm, pre-generated joined lists of user ID’s. That definitely hadn’t occurred to me, and sounds promising. I already have some ideas forming, but I’ll need to sleep on it and mull it over a bit more.

Re the question about new employees, I don’t think that will be an issue because the types of announcements this will be used for are only relevant for a short period. And so older announcements wouldn’t be of interest to new employees. (Actually, I think I just figured out how I could deal with that, anyway :grin:)

Thanks guys!


@Jeff_Hager @Robert_Petitto I’ve taken your advice and gone with the pre-generated joined lists approach - with a few little twists along the way - and it’s all coming together quite nicely. Adapting bits of trebuchet as well as a modified version of Jeff’s multi-select example. I think this is going to be a very nice solution, will post something when I’m done :slight_smile:


Oh gosh, didn’t have time to see this thread yet, but soon I will!!

1 Like

haha, it’s okay - I pretty much have my solution now. Will share when I’m done