Uninstall a ServiceNow pluginIssue Occasionally it may happen that you want to remove a plugin from your system.Is it possible to uninstall a plugin that is activated on the instance?ReleaseAnyCauseMind you that there are 3 types of what people sometimes call "plugins";1. Base plugins, global scope only, these typically have an ID starting like com.glide for example and these are shipped with the base platform.2. Scoped plugins, global or application scope, typically the ID starts with sn_ and these are shipped with the base platform.3. Scoped applications, global or application scope, the name starts with x_ with an additional prefix indicating the customer company or a vendor name and they are installed from a private (git) repository or from the service now app store.This mainly article relates to core plugins as per #1 (in some cases things apply #2).ResolutionHow to uninstall a plugin?The Service Now documentation is very clear in this area, see ServiceNow Plugins: Note: After a plugin is activated, you cannot disable or deactivate it. If needed, you can hide the functionality. You should thoroughly test, in a non-production instance, the specific features and functionalities that are installed when you activate the plugin before using them in a production instance. When a plugin is activated, the installation process performs table schema changes and loads XML files (data, configurations, etc.). Deactivating the plugin does not roll back or disable these changes. Manually removing records by deletion can cause unexpected behavior. If the new functionalities are impacting users, it's recommended to either disable* or update the new functionalities and/or restrict access to them through the use of roles and ACLs.*If any, you could hide the Application Menu from the Filtered Navigation. You can hide it by doing the following:- Go to System Definition > Application Menus- Under title, search for the plugin- Open the entry and uncheck "Active" box- Save and re-loginIf a plugin has very recently been installed there may be a rollback context available to revert the changes, use this as last resort for production scenario's.This will not always undo all schema changes to prevent the potential of data loss (for example if the max length of a column on task was increased and that column is shared with other children of task)For sub-production instances, as long as production does not have the plugin installed/active, clone or restore that configuration over the sub-production instance to get rid of the unwanted plugin installation, this way you are ensured that the configuration again closely resembles production, this you want at all times to ensure there are no unexpected differences between instances while promoting changes through the development cycles.Related LinksPlugin rollback and delete recovery Restrict access to an application Use the Rollback Contexts module to rollback a patch upgrade or plugin activation