Skip to main content

Hi,

We have a business need where our IT users expect to have a manageable list of assignable Assyst users to search from, which conflicts with the need to have visibility into exactly who has updated an event in the self-service portal.

Is it possible to prevent alias (also integration users?) from appearing in the Assyst user lookup in internal assign actions, without moving them to a separate service department that can't receive events?

I'm having issues mapping out how to avoid this cluttering problem where the event form's assigned Assyst user dropdown and internal assign action lookup fill up with non-human and non-alias users (Contact User Alias users, integration users, etc.), while still allowing functionality like the major incident This affects me to work.

My understanding is that the alias user must be in a service department capable of receiving events, but this also adds the current main alias user, and more importantly any potential personalized aliases, to the already long list of Assyst users when trying to assign an event.

Expanding the list of alias users to mirror each contact user seems like a necessity to differentiate which end user performed an action, and to determine whether the actioning user is the affected user, the reporting user, or a follower who has updated the self-service portal. However, this would massively increase the number of Assyst users in our system, making such lookups very inconvenient and adding maintenance overhead for correcting inadvertent assignments.

I’m assuming CSG is involved in the go-to solution here, but is there correct, or is there some other functionality or setting that I might have overlooked so that its still possible to know exactly who has updated an event?

Be the first to reply!

Reply