8 Replies Latest reply on Jul 17, 2017 4:26 PM by nswosr

    Service Request - The basics?

    MarkLarvo Rookie

      Very new to this software so grasping for some basic concepts...

       

      Service Requests. Why would you not want the Requestor and Customer to be the same?

       

      I understand that Self Service uses the currently logged in user to display eligible offerings, yet I can type in a completely different Requestor!?

      For an Assisted Service Request (via a Service Desk team member) we must type in a Customer name to display eligible offerings, yet again I can type in any name for the requester?

       

      In the self-service situation that an assistant creates a request for their executive, the customer becomes the assistant. How would we report stats on the executives requests? Shouldn't the customer be the requestor?

       

      I've created a Service Request(SR) for a MiFi (Aircard) request. On the form for the Requester field I drop in the CurrentUserDisplayName by default, which can be overwritten, and also lookup their Location and Room number to save them data entry steps.

       

      • In Self-Service, how can I make the Requestor Name populate into the Customer Name field?
      • In the Assisted Request, how can I make the Customer Name populate down into the Requester Name field?

       

      Is there any documentation that explains the theory behind the design of this module and the way intention of the way the data should flow?

       

      Thanks

        • 1. Re: Service Request - The basics?
          MarkLarvo Rookie

          And why does the SmartPhone Request not have a Requestor field?

          • 2. Re: Service Request - The basics?
            nswosr Apprentice

            In my organisation, the customer (intended recipient) is the person for whom the work of the ticket is intended, whereas the Requester is the manager or person reporting where the cannot or

            is not authorised to request.

             

            With assisted self service, the situation is still valid as the person typing it in may not be the requester or customer (thus we have a created by field)

             

            In many of our Service Offerings we have a check box asking if the person logging the request is the manager or the customer.

             

            ITIL Service Management might useful as a reference

            cheers

            donns

            • 3. Re: Service Request - The basics?
              James.C Rookie

              Mark, I have the exact same scenario and looking for the same exact solution as you.  Would be great to know of a way to force the two fields to match. 

              • 4. Re: Service Request - The basics?
                nswosr Apprentice

                You could do this with an Update block in the workflow.

                 

                Where you are trying to find the actual user - we have a checkbox - Is this for another person ? (forme)

                then into a field called actualuser we test.  targetname is 'another person' info

                if forme == true

                  then targetname.selected.Employee.DisplayName

                  else CurrentUserDisplayName()

                 

                the offering collects who logged the request, other person (if applicable) and then puts that into actualuser

                 

                then in the workflow an Update block is used to fill the Requestor and/or the Customer from the actualuser

                so in the Target Object

                AlternateContactLink    $(GetSRPValue(RecId, 'requester'))

                Contact Link                 $(GetSRPValue(RecId, 'actualuser'))

                or both as actualuser if that is what you need!

                 

                hopefully that makes sense

                1 of 1 people found this helpful
                • 5. Re: Service Request - The basics?
                  MarkLarvo Rookie

                  Thanks, while I don't quite understand the syntax yet, it is helpful!

                   

                  I have not yet tackled workflows but what I think you are saying is that the Workflow update block is used to pass the Form Field Variables into the Service Request record fields. Right?

                   

                  Meaning, for every field where I want to save the values recorded in the Form in the Service Request for later reporting I will have to:

                  1) Create an actual field in the SR record.

                  2) Add the field in the form for each Request Offering.

                  3) Use a Workflow Update block to copy the form field (like "Unique ID: date_1") into the Service Request's "DeviceReturnDate" field.

                  4) Update, Form: ServiceReqHeader.New to include any of these new fields that we want the service desk team to be able to edit.

                   

                  Since I am here I am posting the MiFi form I've created for comment, suggestions or to possibly help others:

                   

                  ivanti SR board #1.jpg

                   

                  ivanti SR board #2.jpg

                   

                  ivanti SR board #3.jpg

                  • 6. Re: Service Request - The basics?
                    nswosr Apprentice

                    It will drop everything into the parameter tab if you have no other instructions

                     

                    I use the update block to send data to a specific field/s.  I created a field in the ServiceRequest BO called genreq to which

                    I direct the contents of the parameter tab.

                     

                    In a Request Offering I have a couple of field I use for reporting and use the Update Block to direct into certain fields for reporting.

                    These fields are not visible to the client - I set the visibility to none - like the actualuser field.

                    1 of 1 people found this helpful
                    • 7. Re: Service Request - The basics?
                      MarkLarvo Rookie

                      Very helpful, thank you!

                       

                      So to take this a little further... I've only been at this for 2 weeks now. ;-)

                       

                      If you use a Form Offering with Self-Service for a "printer out of toner", a process that writes directly to Incident object fields, do you have any workaround for an assistant making Self-Service requests for their executives?

                       

                      It would seem to me that we have to drop/ignore the Customer field from our forms and create another field "Actual Customer" field that can be populated by both Self-Service and the Assisted Service Request. This would need to be done for both Incident and ServiceReq.

                       

                      I'm also asking this via official support but wondering what others have done. Thanks!

                      • 8. Re: Service Request - The basics?
                        nswosr Apprentice

                        In that circumstance I'd create a new form in incident which has all the things in it you need.

                        like the actual customer and reported by person, HEAT already knows who the logged in user is  and with a little

                        logic it can populate the customer and fill the reported by as the logged in user (which is the same if they put their name into customer)

                        and you could add a field to ask for the printer name which could be a dropdown

                         

                        incident already has a relationship to Request Offering, though I believe you need to publish the form to self-service and I'm on the

                        learning curve for that myself

                        1 of 1 people found this helpful