- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-14-2017 07:13 AM
Hello Community,
I've been trying to create a connect action that will create a new record in a table called new_call, populate some fields, and then set the chat records to the activity list of the new_call record. This is very similar to the existing action that creates a new Incident record from a chat session.
I can get the basic action working fine, I'm having trouble figuring out how to set the chat queue records into the activity list of the new_call. I've setup an Activity Formatter on my new_call form. I can see that any new incidents created with the out of the box "Create Incident" action appears to push all chat records into the 'comments' field of the Incident, which then populates this in the activity log. The problem I have is in trying to figure out how those values are being pushed to the incident table so that I can replicate this for my new_call table. On the default incident action, if you fire the action to create a new incident it will copy an existing chat records into the comments field, and then any new chats that are exchanged get added to the Incident after. I would like to replicate this for my action creating records in my new_call table.
Has anyone sorted out how these records are pushed from the chat table to the incident in the default action?
Thanks in advance!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-23-2017 06:16 PM
Hi Michael,
The important tables are:
live_message
chat_queue_entry
live_group_profile
sys_journal_field
Here's how the Connect Chat activities end up getting displayed in the Activity Stream of an incident:
- Someone starts a chat window.
- This generates a live_group_profile: The "Conversation", the group of people who are collaborating on something (used for both Connect Support and Connect Chat).
- It also creates a chat_queue_entry, where comments and work_note information will be stored against.
- Finally, it creates the first Chat message (live_message) record that contains the auto response information.
- Now at some later point, it is decided to open an incident from the chat.
- When this happens the live_group_profile gets connected to the incident and no longer connected to the chat_queue_entry.
- Also, the sys_journal_field records that were connected to the chat_queue_entry record get copied over to the new target Incident.
- The chat_queue_entry record itself stays open and any new chat messages go to the Incident journal fields too.
When someone is looking at the incident form "Activity Stream" (or "Activity Formatter" in older UI versions), all they are looking at is the combined list of entries that went into the sys_journal_field table.
I'm guessing that you already set the new call "call_type" to "status_call" so that it doesn't automatically create the target record right off the bat
(see Chat Action: Create Call from Chat )
The next step would be to copy over all those sys_journal_field entries from the chat_queue_entry over to the new_call record. We can't do that right in the Chat Action because the new_call record doesn't exist yet, so we somehow need a way to go find the sys_journal_field entries after the new_call record gets created. I think we can get this from the conversation.queueEntry.
https://developer.servicenow.com/app.do#!/api_doc?v=helsinki&id=c_ConversationAPI
1. So make a new field called "chat_entry" on the new_call form of type "Reference" that points to the chat_queue_entry table
2. In the Chat Action, set the new_call.chat_entry field to the current Chat Queue Entry, using conversation.queueEntry.
3. Now create a Business Rule that runs after insert on the new_call table with a condition of !current.chat_entry.nil()
4. Then the Business Rule should go find all the records in the sys_journal_field table where element_id = current.chat_entry and clone them inserting "new_call" for the "name" field, current.sys_id for the "element_id" field, and element_name to whatever journal field you will be tracking it in!
Good luck!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-23-2017 06:16 PM
Hi Michael,
The important tables are:
live_message
chat_queue_entry
live_group_profile
sys_journal_field
Here's how the Connect Chat activities end up getting displayed in the Activity Stream of an incident:
- Someone starts a chat window.
- This generates a live_group_profile: The "Conversation", the group of people who are collaborating on something (used for both Connect Support and Connect Chat).
- It also creates a chat_queue_entry, where comments and work_note information will be stored against.
- Finally, it creates the first Chat message (live_message) record that contains the auto response information.
- Now at some later point, it is decided to open an incident from the chat.
- When this happens the live_group_profile gets connected to the incident and no longer connected to the chat_queue_entry.
- Also, the sys_journal_field records that were connected to the chat_queue_entry record get copied over to the new target Incident.
- The chat_queue_entry record itself stays open and any new chat messages go to the Incident journal fields too.
When someone is looking at the incident form "Activity Stream" (or "Activity Formatter" in older UI versions), all they are looking at is the combined list of entries that went into the sys_journal_field table.
I'm guessing that you already set the new call "call_type" to "status_call" so that it doesn't automatically create the target record right off the bat
(see Chat Action: Create Call from Chat )
The next step would be to copy over all those sys_journal_field entries from the chat_queue_entry over to the new_call record. We can't do that right in the Chat Action because the new_call record doesn't exist yet, so we somehow need a way to go find the sys_journal_field entries after the new_call record gets created. I think we can get this from the conversation.queueEntry.
https://developer.servicenow.com/app.do#!/api_doc?v=helsinki&id=c_ConversationAPI
1. So make a new field called "chat_entry" on the new_call form of type "Reference" that points to the chat_queue_entry table
2. In the Chat Action, set the new_call.chat_entry field to the current Chat Queue Entry, using conversation.queueEntry.
3. Now create a Business Rule that runs after insert on the new_call table with a condition of !current.chat_entry.nil()
4. Then the Business Rule should go find all the records in the sys_journal_field table where element_id = current.chat_entry and clone them inserting "new_call" for the "name" field, current.sys_id for the "element_id" field, and element_name to whatever journal field you will be tracking it in!
Good luck!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-08-2019 09:29 AM
Hi Mwatkins. if by chance you are still following. The instructions may sense, but in London, the Connect Action script OOtB is different.
What is the code for this step "2. In the Chat Action, set the new_call.chat_entry field to the current Chat Queue Entry, using conversation.queueEntry."
The "chat_entry: conversation.queueEntry" in the script below will not copy the chat_queue_entry record to the Call. I am close as "chat_entry: conversation.queueEntry.sys_id" will get me the sys_id of the chat_queue_entry (Task)
response.newRecord("new_call", {
short_description: conversation.document.short_description || "",
caller: conversation.document.opened_by,
contact_type: "chat",
u_work_notes: "Created from Connect Support 'Create Call' action",
//assignment_group: '45c57def132a5280350b50622244b0b2',
//assigned_to: conversation.document.assigned_to,
chat_entry: conversation.queueEntry
//chat_entry: conversation.queueEntry.sys_id
//chat_entry: conversation.document
});
What am I missing? Thanks, Ken
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-25-2020 12:24 AM
Hi Mwatkins,
I've been struggling with this a little today, I can happily create the new_call record and duplicating journal entries is not a problem, however the new_call record is not updated in the live_group_profile nor chat_queue_entry. As a result of this, the record is not shown within the conversation for the agent to reference, nor is the card for the record shown to the customer in the conversation.
I tried to mimic the behaviour for tables that extend task, such as Incident, and so I created a business rule which updates the live_group_profile 'table' and 'document' fields with the appropriate values.. and while this looks correct from both the live_group_profile and chat_queue_entry records, it results in the conversation somehow becoming corrupt and disappearing for both the agent and the customer.
Would you have any pointers as to how I could get this working correctly?
Many thanks!
Grahame
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-25-2018 02:41 AM
Hi All,
In my organization, we are using connect chat however I have a query regarding to the limits of its first message posted to SD. From User end, User is able to type long text but at SD end only 200 characters from the message is displayed and rest is shown as ...... I have highlighted that part in yellow colour. Is there any way to extend its field length. so that SD will able to see all the content whatever has been posted by user.
Please see the attached screenhot.
Is anyone know what to do & could you please let me know how to achieve that.
Quick reply much appreciated!
At End user end, who has posted 400 characters .
At SD end, where we have received 400 charaters however just it doesn't display at SD end's window