@LucyGerber this is a really great idea. Thank you for sharing!

In the meantime, one way you could achieve a similar outcome (to essentially “remove” termed employees from a group) would be to add a new User Additional Field that is something like Active Employee with values Yes/No.

The Employee group would include a rule for Active Employee = Yes. Then, you could add updating this additional field from Yes to No as a part of the process when the employee is terminated and their Termination Date field is updated.

Do you think that could help with your use case?

@LucyGerber you bring up an excellent point and I think that “is blank” and “is not blank” should be  options for a field as well.

For our use case, we have a large group of employees that have data fields that syncs from another database. We need to be able to target certain training to enroll and send notifications to only those employees who have accounts in that specific database. Naturally, if you have a user who does NOT belong to that other database, the data for the field for that user would be blank. If the user DOES belong to that database, the field would have a data in it.

Group A:

All users in Database1

Group B:

All users NOT in Database1

The best way to build the automatic group would be:

Group A:

Database1 field = Is not empty

Group B:

Database1 field = Is empty

@Adam Ballhaussen offers a good suggestion. However, managing an automated group with a non-automated custom field defeats the benefit of having the automated group. The custom field would create more work and maintenance and would not be 100% aligned with the live data available in the synchronized Database1 field. We really need an “is blank” and an “is not blank” option for filtering  system-synchronized data into automated groups.

@kfortenb i agree with you that this could be extremely helpful in a number of use cases.

I’ve heard this topic discussed internally before and understand that our product team previously has shared concerns about the potential impact of a rule like causing frequent heavy payloads on the system for automatic groups. In many situations, having a rule for “Is Blank” or “Is Empty” would likely apply to a majority of users in the platform, and having too many of these rules in a platform (or multiple platforms) could potentially cause latency issues.

With all of that said, that sort of stuff definitely isn’t a part of my job, so I’ll leave it to the experts (our Product Managers) to review your idea and eagerly await their response. We’d likely have good use for this in Docebo University as well, so I’m keeping my fingers crossed for your idea!

Hi @Adam Ballhaussen and thank you for your reply! It is really encouraging to hear that this type of filter is on the radar of the product management team. Even if that type of filter came with the caveat of only allowing that group to update once a week, or you only are allowed 1 refresh for that group periodically (like it would happen with the same data refresh that’s available 1x a day for reporting), that would open up a lot of doors for us. 

That makes sense about the heavy payload, so I can understand why there would be some concern from the product team about implementing a feature like that. But if it could be done... that would really be impactful and enhance the enterprise-level experience for both users and admins.

Thank you for your consideration!