Standards or best practices for requesting on behalf of others

KristinaB
Giga Contributor

Hi there,

What is your standard for allowing the business to request items via the portal. Can they request for themselves only or for others as well? How are you leveraging user criteria to request on behalf of others on the Service Portal.

We've been using SN for 5+ years now and with the implementation of the Service Portal, we have come across some challenges where we want to allow our business users the ability to request on behalf of others

We've set User Criteria on items to allow access to certain items to certain groups of people   i.e. executives have access to request a specific laptop but if you're not an executive, you won't see that item in the catalog

We have set catalog UI policies for displaying some VSETs based on the name of the requested for person in the cart therefore the requested for needs to be identified prior to selecting an item. 2 step check doesn't work for this because the requester is identified at the end of the process

So how are you dealing with this users requesting on behalf of others?

TIA

1 ACCEPTED SOLUTION

Uncle Rob
Kilo Patron

I use User Criteria to ensure that Catalog and Knowledge can only be consumed by appropriate parties.   There shouldn't be a business case where a person requesting X on behalf of another while the requestor does not have access to X.



Here's what I've done in the past, with pretty good success.



All Catalog Items display a variable called "Requested For", which defaults to the logged in user.   The user changes the field if they're requesting for someone else.   I then add the opened_by (physical requestor) to the watch list.   I've also made this optional by having an "add me to watch list" checkbox appear if they change the "requested for" variable.


View solution in original post

7 REPLIES 7

Uncle Rob
Kilo Patron

I use User Criteria to ensure that Catalog and Knowledge can only be consumed by appropriate parties.   There shouldn't be a business case where a person requesting X on behalf of another while the requestor does not have access to X.



Here's what I've done in the past, with pretty good success.



All Catalog Items display a variable called "Requested For", which defaults to the logged in user.   The user changes the field if they're requesting for someone else.   I then add the opened_by (physical requestor) to the watch list.   I've also made this optional by having an "add me to watch list" checkbox appear if they change the "requested for" variable.


Thanks Robert. rfedoruk



We too use User Criteria to limit catalog items to certain individuals and opening this up to allow everyone to request on behalf of other is proving to be quite the challenge. I like your add to watch list option.


Hi, I'm curious if anyone has found a solution to this user criteria dilemma? You say "There shouldn't be a business case where a person requesting X on behalf of another while the requestor does not have access to X" but that is exactly the problem I'm having. A customer submits a call/incident requesting for something they aren't subscribed to, and the technician, who has access to all of the items tries to submit the request on their behalf, unaware of who subscribes to what.

Chris, 

Regarding this...  A customer submits a call/incident requesting for something they aren't subscribed to, and the technician, who has access to all of the items tries to submit the request on their behalf, unaware of who subscribes to what.

On a Call/Incident, you can use Contextual Search to display search results from the Service Catalog (or other sources) based on some field on the form (for example, Short description).  By default, that displays the search results as the technician, but you can also add the search results as they would be available to the "Caller".  This is what we've implemented for Call.  You should also be able to do it for Incident.  Maybe this will help?


Susan Williams, Lexmark