Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Geneva Patch 3 Hot Fix 10

Log in to subscribe to topics and get notified when content changes.

Geneva Patch 3 Hot Fix 10

Geneva Patch 3 Hot Fix 10 provides fixes for the Geneva release.

For Geneva Patch 3 Hot Fix 10:
Build date: 05-10-2016_1635
Build tag: glide-geneva-08-25-2015__patch3-hotfix10-04-21-2016

For more information about how to upgrade an instance, see Upgrade to Geneva.

For more information about the release cycle, see the ServiceNow Release Cycle. For a downloadable, sortable version of Geneva fixed problems, see KB0598265.

Note: This version is approved for FedRAMP.

Fixed problems in Geneva Patch 3 Hot Fix 10

Problem Short description Description Steps to reproduce


Support agents cannot join record conversations on records they create in support conversations Support agents cannot join record conversations pertaining to the records they create from a support conversation. This is because the conversation is being spawned using the same record that the support conversation is tied to. This issue was fixed in Helsinki but is still an issue in Geneva.


Add ability to make custom Idle time message and add it as Macro As admin, you should be able to:
  • Customize the idle message for an end user
  • Customize the last message for an end user (when agent closes a chat)


Need method to specify Chat Actions [connect_action] order and display Need method to specify the order and display of Chat Actions [connect_action]. In a Geneva instance:
  1. Ensure these plugins are active: Connect, Connect Support.
  2. Ensure this property is true:
  3. Navigate to Connect Support > Administration > Actions.
  4. This list displays:
There is no Order column on this table. Prior to Geneva, legacy Chat installed Chat Actions [chat_action] table with an Order filed (i.e. <order>100</order>).


Connect Support 'idle time' properties should not be hard-coded Two properties related to 'idle time' should be configurable:


Connect Support - Chat Queue Entry: Unexpected results for aggregate data (wait time and action) make reporting and tracking difficult/impossible Chat queue entry data is generated in a way that seems strange to administrators and makes reporting difficult. Specifically, the wait time appears to be updated to match the total duration when the session is closed, and the action is set to abandoned when complete. However, this does not align with customer expectations.
  1. Activate the Chat plugin.
  2. Activate the Connect Support plugin.
  3. Open two distinct browser sessions, one impersonating Joe Employee, the other impersonating Fred Luddy.
  4. As Joe, navigate to this URL and start a chat: $
  5. As Fred, accept the chat, then:
    • Bring up the chat queue for Service Desk chat.
    • Find the Chat Queue Entry for the chat you just created in the related list.
    • Note the wait time and action. The wait time should reflect the amount of time that the user waited for the chat to be accepted, and the action should reflect 'accepted'. These values make sense.
    • Send a few replies to the chat.
  6. As Joe, send a few replies to the chat, then:
    • Realize that you no longer need assistance and attempt to close the chat. You cannot.
    • Send a message to Fred indicating that you are good to go.
  7. As Fred, end the chat, then:
    • Navigate back to the chat queue entry for the chat.
    • Note that the wait time matches the duration and that its status is 'abandoned'.
Summary of issues:
  • The wait time should not change, but it seems to reflect the total duration of the chat instead of only the wait time.
  • The action shows as 'abandoned', which seems a bit strange since no one actually abandoned the chat. The customer expectation is that 'abandoned' should only be set when the user leaves a chat before it was accepted, and there should be other actions to indicate that the issue was solved in the chat or that the chat was transferred to an incident.
  • The action shows as abandoned even if you create an incident from the chat.


Presence kill switch does not stop all Presence requests The property glide.ui.presence.disabled does not shut off all presence requests. The presence system is looking for $window.NOW.presence_disabled, but that value is only set if ng_amb_header.xml is included on the page in question. Not all implementations of presence are including this template.
  1. Set glide.ui.presence.disabled to false.
  2. Open the main frameset.
  3. Open Chrome developer tools and look at the network requests.
Notice that requests for presence are still being executed.


Angular AMB client and Vanilla JS AMB client do not have the same API In Geneva, there are two versions of the AMB client. One is created by Angular apps and the other is created by Vanilla JavaScript apps. Only one client exists on the top frame, and it can be created by either an Angular app or a Vanilla JavaScript app (the client object can be used in either environment). There is, however, one difference in their APIs. The Vanilla JavaScript client has a method called "getState", while the Angular client as a property called "state".

Some consumers of AMB (Record Presence in particular) rely on the connection state to decide if they should publish messages. A consumer of AMB will fail If it expects one variant of the state API but gets the other instead.

Open sessions as two separate users on a Geneva instance without Connect enabled.
  1. View an incident in the navigator with User A.
  2. View the same incident in the navigator with User B.
Notice that Record Presence is not visible for either user.


Last support chat gets stuck on screen and agent cannot close it The last support chat cannot be closed, and the agent ends up always having something on the screen. Records created off of this chat end up in an odd state that prevents a session to from being closed and removed from the screen.

Agents should not see chats that were previously worked if they completed the transaction. The conversation is getting into an odd "visible" state.



snTabActivity loses track of primary tab when Connect is not installed The tab tracker (snTabActivity) loses track of the primary (currently used) tab when Connect is not installed. The general UI does not include a unique key to keep track of the tab, which lets form pages override the "primary" tab when they load. This then causes presence to act inconsistently. On a Geneva instance (without Connect installed):
  1. Log in as System Administrator. Note the presence indicator in the top right is green.
  2. Navigate to a form.
  3. Wait 15-30 seconds.
Note the presence indicator disappears in the main nav. This may take a few tries of navigating to a form and waiting for at least 15 seconds.


Customers activating Connect Support need to have legacy chat conversations moved to the Closed Complete state When customers who have previously used legacy chat set a conversation limit in Connect Support, some support agents are unable to accept Connect Support conversations. This is because the system stores Connect Support conversations on the same table as legacy chat conversations, Chat Queue Entry [chat_queue_entry], and legacy chat conversations use a different field than Connect Support to indicate closure. If an agent is assigned more legacy chat conversations than the number specified in the property, that agent cannot accept Connect Support conversations because the legacy chat conversations are seen as active.
  1. Have a few help desk chats open as an agent using legacy chat.
  2. Activate the Connect Support plugin.
  3. Set the property to 1.
  4. As an end user, initiate a Connect Support conversation.
  5. As a Connect Support agent, try to accept the conversation.
The system will not allow the agent to accept new support conversations.


Closing a chat session on an end user's side does not move chat into Close_Complete
  1. Start a Support conversation.
  2. As the end user, click End chat.
Verify that the state does not change to 'Closed_Complete'.
Platform Performance


Session timeout broken by active AMB requests AMB sends are treated as user traffic and keep a session alive.
  1. Open up any user record form.
  2. Leave the browser open.
The session never times out. As you can see below, we issue these AMB requests periodically as part of record presence, thus breaking session timeout while on a form:
2016-04-19 06:17:52 (867) http-48 New transaction 75613FBADB36120075A8317EAF9619B8 #1883
  send /amb/sn/rp/sc_req_item/1a517bb2db7612001f49d29eaf9619fa 
2016-04-19 06:17:52 (904) AMB-thread-2 75613FBADB36120075A8317EAF9619B8 #1883
  send /amb/sn/rp/sc_req_item/1a517bb2db7612001f49d29eaf9619fa Message ------------------------- 
2016-04-19 06:17:52 (915) AMB-thread-2 75613FBADB36120075A8317EAF9619B8 #1883
  send /amb/sn/rp/sc_req_item/1a517bb2db7612001f49d29eaf9619fa --
  total transaction time: 0:00:00.048, transaction processing time: 0:00:00.048,
  total wait time: 0:00:00.000, session wait: 0:00:00.000, semaphore wait: 0:00:00.000,
User Interface (UI)


Presence indicator missing on navpage header if Connect is not enabled Customers who have UI16 enabled but NOT Connect will not see the presence indicator in the nav page header. This only affects the user's avatar in the navpage header.
  1. Upgrade an instance from Fuji to Geneva OR remove the Connect entry in sys_plugins.
  2. Ensure presence is enabled.
  3. Load the navpage.
Notice the green dot is missing. You should still see presence on VTB and on the form activity stream.

Fixes included with Geneva Patch 3 Hot Fix 10

* Unless any exceptions are noted, you can safely upgrade to this release version from any of the versions listed below. These prior versions contain PRB fixes that are also included with this release. Be sure to upgrade to the latest listed patch that includes all of the PRB fixes you are interested in.

  • The fixes for Geneva Patch 2 and Geneva Patch 3 were combined into one patch. ServiceNow documentation refers to this combined patch as Geneva Patch 3.
  • Geneva Patch 3 Hot Fix 4 does not exist.