Best Practices: RITM without a Task

[tayrez]

What is the Best Practice around RITMs and Tasks?   There are situations where it would be easier for one of our groups (3 agents) to just work from the RITM and not have a task. We don't need approvals and one person works on the RITM at a time.   What is the best approach?

Thank you.

Therese

[tayrez]

Hi Doug,

It's interesting to hear what you do. Am I understanding this correctly?

1. You are assigned a task and you need to communicate with customer so you go to the parent item (RITM) and communicate via Additional Comments.
2. When you click update, a BR places the Additional Comment you just entered into the Task Work Notes. How do you identify which task it should go to if you have multiple tasks?

Thanks,

Therese

[randrews]

sorry i was less than clear let me explain...

we have 2 BR's regarding this...

1> copies all additional comments from a task to it's parent items additional comments

2> copies all additional comments from an item to it's child tasks WORK NOTEs <that is important to prevent a loop>

we have 2 notifications

1> when the item additional comments are updated the customer gets them in an email

2> when the task worknotes are updated the assigned to gets an email <uncheck send to event creator to avoid extraneous emails>

so when an additional comment is updated in a task... the requested for gets an email... furthermore those notes are copied to ALL child task work notes notifying anyone else with a task on the same item of the comment.

when the additional comments of an item are updated <say from an incoming email> all child tasks are updated and the owners get email on it.

we have one other way for people to tell a task has been updated... we have a style on the number field on task to turn it blue with the following condition...

javascript: !current.assigned_to.nil() && (current.assigned_to.user_name!=current.sys_updated_by) && (current.sys_updated_by!='system')

this turns the number blue if the assigned to is not the same as the updated by <this helps techs find tickets they need to take a look at>

[georgimavrodiev]

Hello Raymond,

Last week I had a requirement similar to yours.
I needed to ensure that the comments of a Task record (sc_task) will be visible in the specific Request record (sc_request) and vice versa.

I created two Business Rules. My goal was completed, but yet I encountered the issue with the loop for which you are speaking about in your above comment.
Or in other words: I had duplicate comments in the task and request records.

After some thinking on the matter, I modified the scripts of my Business Rules and managed to fix the issue.

Just from curiosity (to see how other people here, in the Community, managed to deal with this problem) I reviewed your comment.
I have to say that I tested your suggestion (the comments of a task to go to the requested item (in my case: request) & the comments of the requested item (in my case: request) to go to the work_notes of the task). Yet, I ended having duplication (single line or better to say: smaller duplication) of the comments in the Task record (sc_task).
Thus, I went back to the solution I originally created.

This means that you also have the same duplication problem in sc_task. Is that so?

If Yes, then I would suggest you to use a prefix in the BRs' scripts.
Leave the comments of the task to be equal (=) to the comments of the RITM and the other way around, but use this line of code in the scripts of your Business Rules: "gr.comments = '###     '+current.comments;"
This way, you will deal with the loop. There will be no more duplicate comments in both the records.
In addition, you may add the following text to the prefix:
- in the Business Rule which runs against sc_task: "gr.comments = '### Fulfiller reply:     '+current.comments;"
- in the Business Rule which runs against sc_req_item: "gr.comments = '### Customer reply:     '+current.comments;"

Or change the text as per your requirements.

Best Regards,
Georgi Mavrodiev

IT Consultant
Do IT Wise

You may visit us in our Web Site: www.doitwise.com

[BryanS413339635]

We're doing everything the same as described, but found that the notifications didn't suffice in keeping support staff up-to-date. So what we did was setup a BR that updates the status of the ticket when a customer replies. So support staff emails the customer and sets the state to 'Awaiting Customer'. When the customer replies it updates the work notes and sets the state back to Open (or Active for Incidents). From their it's up to the support staff to be properly managing their work and addressing Open and Active tickets.

[tayrez]

Thanks!