Best Practice: Record Producer vs. Catalog Item

[Inactive_Us1175]

Hello,

I have already researched this and come across a multitude of answers, views, and openions. I was hoping to find a clear answer in the ServiceNow documentation but I couldn't find one (there could potentially be one, but perhaps I was looking in the wrongs place).

Here is the situation:

I have recently moved to a company with a mature ServiceNow implementation. I went through a full implementation with my previous company, and there we made sure to follow the ServiceNow best practices, as per the ServiceNow consultants and implantation partner.

What I found at my new workplace that they have been using record producers for most of their requests/incidents, on all modules (they have ITSM, HR, Risk Management...etc). Personally, I was used to creating requests, as requests (Request -->ITEM-->TASK), and utilizing workflows, as we were advised that this is the best practice, especially for multi task type requests (some requests have 3-20 tasks). Here however, they are using record producers, and applying workflows to them using conditions that run against the target table.

I advised that we should use Catalog Items instead of record producers for requests, especially if they require a workflow to generate tasks. I was asked "what value would that bring?", which is a fare question. In record producers you maybe to use templates and scripts to fill some fields upon form submission. But technically you could do the same on a request in a number of ways, including scripts in the workflow. 

so what is the best practice? Should they be using record producers with all these scripts, and linking workflows to them isnt it best practice to create requests as requests, instead of incidents on the incident table? wouldn't generating a task using a workflow on a record producer generate a parent-less task (no request or requested items associated). if so, what are the down side to such process? wouldn't running workflows using conditions against tables result in a performance issue, since the condition has to run against each new record created for that table to see if it meets the requirements? 

Life was simple for me when Requests were requests, and incidents were incidents lol!

Sometimes the difficulty of working with the NOW platform is in the multitude of ways you can do the same thing, but no clear indication on what is a best practice.

Any insights are appreciated.

[Uncle Rob]

I don't make my distinction by presence of workflow.  I make my distinction by where the target record belongs, and if there's a pre-existing table.

So I have no problem at all with Record Producers pushing records of specific types to specific tables.  And now that we  have FLow Designer, its way more intuitive to add workflows to the destination tables involved.  But its worth noting, Workflow was *NEVER* exclusive to RITM.

I use Catalog when I just have to do work tracking with workflow and I don't have a specific table for the process in question.

(Credentials:  12 year servicenow architect)

[Allen Andreas · Accepted solution]

The workflow runs against the target table for requests too...like you'd normally set the workflow to the sc_req_item table. So they are doing record producers (which by the way are still considered a form of catalog item) and the workflow runs against a specific table that way.

Unfortunately, you were there to "implement" what they did. You said they have a mature environment. So you can bring up your concern, but if they don't want to redesign the entire platform, you'll have to adapt. If they use a workflow against a target table, you can create tasks (not catalog tasks) and it'll go right to that table (if it extends from task).

Sometimes the amazing thing with working with the NOW platform is the multitude of ways you can do the same thing. 

This post has some discussion about it that makes some good points: https://community.servicenow.com/community?id=community_question&sys_id=acd40fe9dbd8dbc01dcaf3231f96...

Ideally, requests/catalog items in the cat_item sense is that it's used for ordering something, using a workflow with approvals and generating tasks. Record producers are more of a "straight to the point" type of process where you fill out a form and bam, it's turned right in to a record. You can still add a workflow to a record producer and do all that, but I wouldn't personally go that route.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Inactive_Us1175]

Thank you guys!

Both answers were very helpful answers. I understand that workflows are not exclusive to cat_item type of requests, I was caught off guard however when I found that they are using record producers to generate tasks with approvals and such (regardless of module such as ITSM HR...etc). Not to mention how all requests are created in the incident table or hr_case for HR. While it does work, it is not ideal as you have mentioned.

Going forward, for new development, I will discuss with the team if we can go back to creating simple forms as record producers, and more complex ones (including tasks and approvals) as cat items. For the end user or the fulfiller, things will not differ from and interface perspective, so things should be fine.

[William Busby]

Keep in mind ServiceNow documentation specifically states you should not use record producers for creating requested items [sc_req_item]. Not implying you are doing this, just making sure it's clear.