HI @ksweitzer only other option would be to create a new additional field and store the user’s language preference there. You can also make the additional field visible to users to they can self-select (recommend you build a dropdown) if that’s something you want to allow. As well, with this field set-up as dropdown, you could also use it to filter your reports which may also be helpful for you.
One of the most helpful ones? Purely opinion - Setup an Active User custom field. Groups indiscriminately will hold onto inactive and active users…with this trick? You may stand a chance to drop out inactive users from your groups and avoid having situations that can make inactive users part of your groups that do not really belong in them….
i say it like that? Because not all integrations that are developed will be signal to turn off or term accounts effectively.
Be careful. That also assumes that you do want to drop those inactive users from reporting in certain cases where you are using the group to report out….
We have talked about using an additional field for the user to decide what courses they want to see based upon the language setting they choose for this field - but our concerns would be a potential confusion because they choose language in their profile for system text and then have to choose a different ‘language’ setting for courses. weird...when you should be able to offer up courses based upon the system setting.
I think having a group based upon the system setting for language makes a lot more sense…
Fingers crossed for that one.
@JeanetteMcVeigh theoretically, if you have access to Workato, or similar tool able to consume webhook calls and invoke APIs, you could create an external recipe which will be invoked on each change in users’ profiles and make necessary updates to Additional Fields.
I wrote “theoretically” as it seems that the user.updated webhook is only triggered when an admin is making changes to the user’s profile and not when user is editing their profile themselves on the /my-profile page.
It might be a bug, if you’d want to evaluate that route, you’ll need to work with the support to see if this could be fixed.
The option to create additional user fields works, but why should we have to do this. If the system field is already there why can’t we use it to create groups and filter with. For us it is the Manager Permission field. This indicates who supervisors are and we would like to create groups related to that data.