Division (Branch) is NOT XXX?

Without seeing your branch structure, that could be possible or impossible.

Another alternative is to consider adding an additional field that identifies these accounts, rather than the branch.

The request for updated Group conditions to include “does not contain” “is blank” and “is NOT one of” is in the community.  Unfortunately, has not been added to a roadmap.  Definitely needed.  The option mentioned above to add a User Additional Field to facilitate the group is probably the best bet.  

I just did a quick search but did not find it.

Can you post the link?

It blows my mind that we can specify Users will be included into the group according to the branch they belong to but we cannot exclude Users from the group according to the branch they belong to.

I haven’t found a solution to this either. I find the conditions for Groups to be pretty bleak, otherwise we would use them to a much greater extent if they were developed further.

You can use User Additional Fields as mentioned, however there is a big caveat depending on how users are authenticated. If you have self-registration enabled , even if a User Additional Field is set as required, it is egregiously easily for a user to bypass.

After an account is created and the user logs in for the first time, they are prompted to fill out the required User Additional Fields. All they have to do is click off of the pop-up window that’s prompted, and they are never prompted again to fill out those fields, essentially making it, optional.

This has cost us dearly and we’ve lost the only opportunity to capture thousands of data points in these fields from external/customer-users because this doesn’t function as it should. Perhaps this isn’t as relevant to you, but just a word of caution in case it is.

It’s a pretty essential function used to enroll users.

At this point I am considering using another system to create the enrollment groups by querying our HR Data and assign training because Docebo makes it so hard to have reliable data.

Additional Fields are not the answer, they are prone to duplication through typos and do not retain the parent child structure needed to be useful, Useful, usefull, Usefull, USEFUL.

@tom.albright We have the user branch included as a user custom field ‘location’, and can set a criteria ‘Location is not equal to XXXXXX’.  We do not allow for self registration and have a daily feed from HRS so there aren’t any typo’s that could happen as mentioned in previous responses.  Best of luck!

Thanks, thats a great workaround.

We have a HR feed too, but the minute there are any structural changes done or Cleanup of Names, the Additional Fields become duplicated with the new name or structure, because there is no “Name path” or “Code path” they are created new, the users move from the old to the New field and the old Names remain.

I plan to run a report on the Additional Fields daily so I can see the change (or hopefully no change) in number of results daily.

Also I have been told it is best to use Codes rather than Names to help prevent some of the duplication.

Thanks again!

I like Maz’s suggestion. If you create an additional field, you could then use a User Management batch upload (or API if you’re comfortable with that) to complete the field for everyone, indicating if people should be considered part of your select group or not. Good luck!

Yes, not having the “does not contain” is a huge issue for us too. The easiest way we have found is the additional field option that was mentioned above. But when you have a lot of users it is tough to keep up with it! Good Luck!!!

I don’t know the specifics of your use case, @tom.albright, but if you are using SSO, API, or even CSV, you could map the additional field with the information you are getting from HR. If this is the same as the branch, you could then use the “value is not” for user additional fields. However, you cannot use descendants on this and you would need to add all values manually, but that might be a workaround. 😊

Hello all, we did something similar to one mentioned above as we use a LOT of groups. I added some fields to support data from HR output and then created automatic groups for those. A tedious manual process at the moment. But I am working on automating it with Python or Postman.

I’m not clear what you intend to do with the users that would be in the Group of unassigned users, and I agree that a ‘field is blank’ would be so useful. I have found that on occasion self-registrants end up in the root so I have a schedule report of all users on the platform sent to me weekly, Then I filter the branch column to view “Blank” to know who I need to manage. It’s a workaround, for sure!