Hi All,
One major issue we hit with logging items via the SSP is the ability for staff to log a ticket on behalf of another individual.. Sometimes this could be a PA for a Director, or a colleague logging an item for someone that isn’t able to get on the system.
Currently if we open this up to members of the same Branch(Office) or team - it allows everyone to see all tickets logged/open for that Branch (Office) or Team. This is a major security breach for us as tickets could relate to personal items such as Workplace Adjustments etc or questions logged about a direct line reports activity.
We really need this sorting, ideally anyone should be able to log a ticket against any other user, unless we specifically set the Caller field in an SSP form to not allow the value to be edited.
Anyone have any thoughts on this?
SSP - Allowing users to log tickets on behalf of another Caller (anyone in GAL)
+1
Common work arounds for this limitation in form designer functionality are:
- Use custom forms
- Use an optional search list (dropdown) and populate it with person data using a custom import
- Import it for example like “John Doe (johnd@company.com)”
- after form submission, use an action sequence to set the caller of the ticket to the affected person in the free searchlist (or link them / share the ticket with them)
- Import it for example like “John Doe (johnd@company.com)”
+1Common work arounds for this limitation in form designer functionality are:
- Use custom forms
- Use an optional search list (dropdown) and populate it with person data using a custom import
- Import it for example like “John Doe (johnd@company.com)”
- after form submission, use an action sequence to set the caller of the ticket to the affected person in the free searchlist (or link them / share the ticket with them)
- Import it for example like “John Doe (johnd@company.com)”
That has been a consideration but to try and maintain a list when staff are in 000’s is not that easy and it is crazy where the ‘Caller’ field can already be made editable.
We just need to find a way to cleanly split the ability to log as others from the view of other callers tickets.
In that scenario you don't maintain that list manually, it's synchronized nightly (or multiple times a day) directly from the TOPdesk person table.
+1Are you able to create an Action Sequence to change the caller after the ticket is created? The idea is to use an email field in the SSP form as a key to identify the actual requester.
ACTION SEQUENCE FLOW:
Ticket created → GET PERSONS the person using the email provided → PATCH INCIDENT updating caller.id with the returned ID.
This way, the person who submitted the ticket will not see the real requester’s details. If I understood the problem correctly, this should solve the security issue without losing the ability to create tickets on behalf of someone else.
I’m assuming that all requesters already exist in TOPdesk and have either an email address or another unique identifier that can be used to find them.
I don’t get it.
Why isn’t this a functionality “out of the box”?
If I would use custom forms, why should I consult a TOPdesk advisor when I expect to be able to set up the feature myself?
Why can't I design the form myself to meet my requirements? This is not an unusual or new application scenario.
Currently, we are getting around this by asking reporters to enter the email address of the relevant person. With an automated action triggered by the operator we look up to the associated mail and its user.
Unfortunately, this only works to a limited extent as I cannot specify a syntax for the input field (in this case, email).
Due to human error, the automated action does not always run reliably.
I don’t get it.
Why isn’t this a functionality “out of the box”?
Fair point, it should be. The form designer currently only covers the use case of a manager requesting for their subordinates, not peers for each other.
If I would use custom forms, why should I consult a TOPdesk advisor when I expect to be able to set up the feature myself?
Why can't I design the form myself to meet my requirements? This is not an unusual or new application scenario.
Technically you can. Maybe get in touch with us to discuss the details.
Currently, we are getting around this by asking reporters to enter the email address of the relevant person. With an automated action triggered by the operator we look up to the associated mail and its user.
Unfortunately, this only works to a limited extent as I cannot specify a syntax for the input field (in this case, email).
Due to human error, the automated action does not always run reliably.
Human error can be eliminated using a drop-down field instead of a text field. (Importing your persons into a free drop-down field nightly).
Login to the community
No account yet? Create an account
Login with your MyTOPdesk account
Log inEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.