Any instance originally created prior to June 2010 does not have the Subscription Based Notifications plugin activated and may encounter the following issues during an upgrade.

  • If the instance is upgraded to Dublin Patch 0, Dublin Patch 1, or Dublin EA 8: Certain base system email notifications may not function. Conditions will not evaluate properly for "Record Inserted or Updated" notifications.
  • If the instance is upgraded to Eureka Patch 0 or Eureka Patch 1: The upgrade process will be significantly delayed while the Email [sys_email] table and its associated rotation shards are modified to add a new column to the table.
Two issues can arise when this plugin is not active:
  1. Calgary, and Dublin instances will not be able to process new-style Email Notifications, which are designed to use "Record Inserted or Updated" features. Old-style event-based Notifications will continue to work fine
  2. Upgrading to Eureka Patch 0 or Eureka Patch 1 with many rows in the sys_email log tables, can cause a very long upgrade time. Tests show that an instance with 70 million sys_email records will take 8 hours to upgrade.
    • During the upgrade/plugin activation, certain forms (such as Incident) will show errors and be unusable
    • During the upgrade/plugin activation, no Notifications emails will be created or sent, and will be lost permanently. There is no way to re-generate those Notification emails

How will I know if my instance is affected?

Navigate to https://<instancename>.service-now.com/nav_to.do?uri=v_plugin.do?sys_id=com.glide.notification to verify that the plugin is active. If the plugin is active, your instance will not experience this issue. If the plugin is inactive, your instance is affected.

Here are some possible questions you might have, with answers: 

Question: Why is this plugin not already activated on my instance?
Answer: Instances built prior to June 2010 did not have this plugin. Newer instances activated the plugin by default (for zboots and new builds), but upgrades did not force the plugin to activate.
Question: What if I don't activate the plugin?
Answer: Your older, event-based Notifications will continue to function. However, some of the base system Notifications will not function, specifically ones that use Berlin’s "Record Inserted or Updated" feature.
Question: Why does it take so long to activate the plugin or upgrade to Eureka?
Answer: The plugin adds a new column to the sys_email table. Depending on your instance’s email volume, the sys_email table can have many Table Rotation shards, each of which can have many rows. It takes a long time to update a single table that has many rows, and even more time to update each of the shards. This can add up to several hours (In our tests: 8 hours for ~70 million records, across ~32 shards)
Question: What if I activate the plugin (or upgrade to Eureka) and continue to use my instance during the activation?
Answer: Many functions of your instance will work fine, but any page that depends on related records from the sys_email table (Incident forms, for instance) will show SQL syntax errors as the queries require the new column to be available across all the shards. Potential data loss: any Notifications that would have been created during the upgrade process will fail silently, and will not be re-created.
Question: I upgraded to Dublin Patch 2, but the Subscription Based Notifications plugin is still not active -- will my Notifications work correctly?
Answer: Yes. The fix for Dublin Patch 2 resolves the issue in a way that does not require you to activate the plugin.



The best solution is to upgrade to Dublin Patch 3 or Eureka Patch 2.

If you are unable to upgrade to Dublin Patch 3, and are currently experiencing issues with Email Notifications, a workaround is to activate the Subscription Based Notifications plugin. See warning below:

Performance Warning: activating this plugin can take a very long time. Instances with 500,000 or more rows in the Email Log (e.g., sys_email table and its associated shards) should be scheduled for this change during off-hours. If your instance has millions of records, please contact the Customer Support Performance team to assist you with modifying your sys_email table and shards.


Related Problem: PRB598568

Seen In

Dublin EA 8
Dublin Patch 1

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2015-12-21 10:03:19