Using RITM vs Catalog Tasks

[JimmieOdelius]

Hi.

I'm wondering how people are "supposed" to work with catalog items.

• The request itself DOES NOT send out information by email to the caller/requester/initiator.
• The request item DOES send out information by email to the caller/requester/initiator.
• And finally the Catalog Task DOES NOT send out information by email to the caller/requester/initiator.

I've currently designed my workflows so that our technicians will only work with catalog tasks, but this prevents customer conversation.

A solution for this could be to use the request item record instead to work with the request but this makes it hard when the request has to be worked on from different assignment groups etc. making a workflow useless.

One solution could be to work with the request item as well as create catalog tasks when other assignment groups need to work on the request. This prevents customer conversation from these "sub-tasks" however as well as we need to teach the organization different work procedures depending on what kind of ticket they are working on which makes this solution not so pretty.

Has anyone here had this issue? How did you solve it?

Ideally we would only work with catalog tasks and simply ignore the request item and request and let the workflow handle them when it's time.

[JimmieOdelius]

Thanks for the list, it helped tremendously and I think I'm on the right track now.

Regards

Jimmie Odelius

[Uncle Rob]

I'll try to circle back on this and share some code.   In the meantime let me make a few points.   Tim provides an excellent list, but I had to take it a few steps further.

As custom apps become more popular, you will inevitably discover that apps are not stand alone silos. Often times you'll need to integrate the record from a custom task into an existing RITM based workflow.   That will add another layer of complexity, since these task types often stand alone OR act as components in a workflow.   In the latter case, the worker is still just commenting through their task, but it has to go to the customer of the RITM.

• I doubled up on my comment notification records for custom task types.   1 for when parent class = RITM, 1 for when no parent class.
• The business rule Tim wrote that pushes to open sc_tasks, actually pushes to all tasks (that are child to the RITM)
• The same rule Tim wrote that pushes to open sc_tasks has a check in my system to *first* send to any open approvers.
• I have a separate custom journal entry field on sc_task & custom task types to hold any communications coming from the RITM (which should be all of them).   This ensures that any sc_task or custom task you pull up maintains the conversation history between customer and worker.

TL;DR

• don't forget about custom task types under RITM via workflow
• don't forget about approval records.

[JimmieOdelius]

Thanks for the more in-depth explanations and suggestions.

We currently don't have any custom task extensions and the likes since this is a completely new instance but I'll try to remember this for the future.

EDIT: And good that you mentioned approvals! I had completely missed those.

Regards

Jimmie Odelius

[Hitesh targe]

I have a requirement to send the notification to task assignment group if there is comments added by requestor. How can achieve this and i have to include the comments in the notification.

currently customer comments are not coming in task activity.

Thanks,

[JimmieOdelius]

Hi Prasa.

I do this by using the fields requested_item.comments instead of the comments field.

This way all tasks updates the Request Item instead comments from the requester will show up in the task as well.

Attaching files is still an issue however.

Regards,

Jimmie Odelius