Best Answer

When Building Automatic "Groups" - Termed employees

  • 1 June 2021
  • 4 replies
  • 113 views
LucyGerber
Rank
Userlevel 3

When building an automatic Group, we need a way to eliminate a termed employee from being added to the automatic group.  The options when you pick “Term Date” do not allow for “blanks” to be an option.  It only allows us to pick a date based on the following:

  1. On
  2. Is after
  3. Is before
  4. Is in the range

There should be an additional option called “if blank” so that when an employee is termed, they would have a date in that field and thus would not be blank.  Therefore, their name should not be added to the Automatic Group being added.  

Otherwise, programmers would need to eliminate anyone that has a term date in their programming code.  

 

icon

Best answer by Adam Ballhaussen 2 June 2021, 11:05

View original

4 replies

Adam Ballhaussen
Rank
Userlevel 7
Badge +3

@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?

Adam B.
kfortenb
Rank
Userlevel 3

@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.

Adam Ballhaussen
Rank
Userlevel 7
Badge +3

@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!

 

 

Adam B.
kfortenb
Rank
Userlevel 3

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!

Reply


Terms & ConditionsCookie settings