Requested Item vs. Catalog Task - confused

Mickey_Cegon
Tera Expert

We're creating our first Service Request in Service Catalog, and I want to make sure I'm not going down the wrong path.

I created a Catalog Item, called Software Request, and a graphical workflow called Software Request Workflow, associated with the Catalog Item.
I have a Record Producer created, where the user fills in the following information:

1. Software Title/Manufacturer/Version (probably 3 fields) - free-form text
2. Department that will be charged for the software if there is a cost involved
3. List of recipients (slushbucket - filtered by Department chosen in step 2)
4. Approver - filtered by Department chosen in step 2
5. Business Need - free-form text
6. Additional information - free-form text

The Record Producer creates a record in the sc_request table, and this is the main record. I get that...But, this is the part I'm confused about, even after I read every wiki and forum article I could find. Do I then trigger the workflow for Requested Item or just use my Software Request workflow? I see OOTB there are 2 different workflows, one for the request and one for the requested item. But, can I just use my request workflow, and create Catalog Tasks for each of the recipients that are going to have the software either manually installed, or installed via SCCM? I've been told I need to have a way that each user has a record of the install, in case they call back to the Service Desk with issues. And, we're eventually going to want to tie the software into Software Asset Management in Berlin, we're just not there yet. What's the difference between logging a Catalog Task per user or a Requested Item per user? We don't have all our software in the CMDB for the Requester to select a specific title and version. We're waiting to see what the new features are in Berlin first.

I have a feeling that if I don't do this correctly from the start, I'm going to have a real mess on my hands.

Mickey Cegon
FBL Financial Group, Inc.

7 REPLIES 7

Jim Coyne
Kilo Patron

You really should not use a Record Producer to create the Request record - your users should be kicking off the process through the Service Catalog page. Once they select the "Software Request" item, they are then presented with those fields to collect the data. Once that is done, they select either "Order Now" or "Add to Cart" and then submit their order. I would probably just go with "Order Now" as this is your only item available at the moment.

Take a look at the following to give you an idea of the flow:
https://demo03.service-now.com/nav_to.do?uri=catalog_home.do?sysparm_view=catalog_test

I created a new catalog page with just that one item to simulate your conditions and a test workflow. The workflow has an approval activity and 2 tasks. Once they order the item, the Requested Item workflow will kick off automatically for you. The OOB workflow on the Request is a little odd - my clients have tended to ignore approvals on the Request record and only worry about them on the actual items.


Mickey_Cegon
Tera Expert

This makes the process much clearer! But, what about the individual recipients? If I'm not logging a task per recipient, where is the record of them getting something installed going to reside? In the Requester's list of records? We have the majority of our requests logged by a person requesting software for a group of folks in their dept. So, if Mary asks for the software for Joe, and a week later, Joe calls the Service Desk w/a problem, they will not see that Joe had something installed that was requested by Mary. Also, the software may be a manual install, where 4 techs have to go to 50 workstations, and the divvy up the work. I'd think that if you assign out each recipient's task to install the software to the techs, then they close each task after doing each install. Last task closes, the request is completed. Does that make sense?

Mickey


Jim Coyne
Kilo Patron

Right, I was just looking at it from waaay above. In this particular case, I would not have a list of users you are requesting the software for, but order it individually instead. I know it may be counter-productive, but if you need to link users to a requested item, this is really the only way.

That being said, there is a feature you could take advantage of, Enabling Bulk Requests, that allows requests to be copied.

However, there are also ways to create multiple tasks manually by using the Run Script activity instead of a Catalog Task activity. You can create the tasks based on a list of users or maybe a list of software items. If you do that, then you can use this post on the ServiceNowGuru site to wait for all the tasks to complete -
Wait for Closure of all Tasks in Graphical Workflow.


Mickey_Cegon
Tera Expert

I think I'm going to end up doing the script to create the tasks. I've got the following script so far:

var users=current.variables.recipients.toString().split(',');
for (var i=0;i
var task=new GlideRecord('sc_task');
task.initialize();
task.assignment_group.setDisplayValue('Software Distribution');
task.short_description='Please install ' + current.variables.software_title;
task.u_requested_for=users;
task.parent=current.sys_id;
task.request_item=current.sys_id;
task.insert();
}


I really appreciate your advice on this. I took a look at that Enabling Bulk Requests option that I'd never seen, and we might be able to use that. But, we get requests where the admin of an area asks for an entire department to get some software, so only being able to copy 10 at a time is probably going to be a show-stopper. And, I know the concept of everyone just asking for their own software isn't going to fly...even if I make the process so simple, there are just folks who want someone else to do the ordering for them.

I'll go ahead and mark this article "answered", since I think I've got it clear enough to move on. Will I be able to get to that demo site for a couple days yet? I wanted to show my Process Owner the examples you made. If not, I can just take screenprints of the different screens.

Thanks again for the timely answer!

Mickey Cegon
FBL Financial Group, Inc.