Extend Request Item and Catalog Tasks

[Katie A]

Hello,

I am creating a catalog item for the first time. Typically I create applications using custom task tables only so the Catalog Item structure (SC_REQ_ITEM and SC_REQUEST) tables are a bit of a new concept. (I do not really see why all catalog items are going into the same table.)

I want to extend the sc_req_item table and the sc_task table in order to create a custom table that is specific to the new item.

Specifically, I have requirements that apply only to a certain item, which require custom fields that pertain to only to that one specific item. I also have to create Catalog Tasks, which have custom fields that pertain only to that specific item. I need to write scripts to check the values of those custom fields.

For example, I am building a Computer Request form which requires that the user's job is validated. I have a Catalog Task called "Validate developer status". The technician needs to make sure the requestor is a developer (manually) and then click some sort of checkbox that says "validated developer status". Then when that task is complete, the workflow should continue a certain way based on that value.

I tried one way by creating a new variable and hiding it on the front-end form so the technician can go in and modify the variable later, but I still need to write scripts that apply only to that Catalog Item. I can't find a way in a script to check something such as "IF Catalog Item == Computer Request { run this code } else { return }. So, I thought it might be a better to create a custom table extended from sc_req_item and sc_task.

Question: I know how to extend the sc_req_item table (make it extensible and extend to a new table) however, is this a best practice? Is this the best way to achieve these requirements? The extensible option is set to "false" by default on that table so I am thinking that this might not be a best practice.

A very similar question is here.

https://community.servicenow.com/thread/170463

[turnea · Accepted solution]

I wouldn't recommend extending the table - my Service Catalog has well over 400 items in it and we use the OOB tables.

There are a few ways that you can get what you want with this:

1) Do what you said and create a variable that only shows up after submission (via Catalog UI Policy).   You can then create an onChange Client Script that will query the specific task short description and make the variable mandatory to be filled in when the task is changed to "Closed Complete" then, if you need to, have an "If" condition in the workflow that will then check that variable and spawn more tasks off of it.

2) Create custom fields on the Catalog Task form for the catalog item and only have them display when that catalog item is selected, or even the specific task is triggered.   You would need to create a UI Policy that would show the field at that time.

We've done both, though we now use the first option more frequently, as we don't like the idea of adding all of these custom fields to the general form.   Variables work best, unless you're looking to report on them (and you're not in Fuji), then I would do the second option.

[Brad Tilton]

Hey Kathryn,

One of the huge benefits of using catalog items is that they're so versatile. Because you can use different variables for different items and now easily report on variables, you don't have to create new tables and add fields for different types of requests. I would definitely not extend the request item or catalog task tables and try to accommodate your requirements through the OOB catalog items and variables. I've had a couple of customers who have extended those tables and we ran into a few different issues with it. In my experience and with the reporting in fuji, there isn't much you can do with fields that you can't do with variables.

One thing you might check out is using workflow variables that don't show up on the front end but you can add to specific tasks in workflows. You can also use run script activities in workflows to take the place of business rules.

[Katie A]

Thanks so much everyone!

I will proceed with using the standard sc_req_item table and working around the customizations using variables.

One more question — would there be any hesitations with using the "Create Task" activity to spawn a custom task type (instead of using the "Catalog Task" activity). That way I can accommodate custom task requirements a little more easily. It is my understanding from the wiki that both "Create Task" and "Catalog Task" seem to be acceptable practices.

Thanks again!

[turnea]

I would hesitate to do that as well.   Unless you're creating a change task or an incident or something similar, Create Task wouldn't be the right option.   All Service Requests that I've used only utilize the Catalog Task workflow activity and work fine.   The tasks that are created can be customized within the workflow.

If you wanted to let me know a type of request you're trying to create with the workflow you're envisioning, I could take a look at it.   I am a Service Request process admin as well as I develop service requests on a regular basis at my company, so if you were open to it, I could try and help.