Application developers must manually save a copy of each application currently in development prior to cloning over their development instance. Published applications having same version in the source & target instance are preserved during the clone. But application having different versions or application only present in the target instance must be preserved either by exporting the XMLs or linking them with a source control system. Find additional information here.

Go to https://apprepo.service-now.com. Log in using your HI credentials. Next to the application listing, click Select Action and then click Flag for Deletion. On the confirmation window, click Yes. After you flag an application for deletion, the application is deleted automatically after 90 days. To delete the application immediately: Open the Flagged Apps tab. Next to the application listing, click Select Action and then click Delete Immediately Note : Customer admin on HI can delete an application only if the application is not installed on any of your company instances. Uninstall the application on all your instances before deleting it from the application repository.

The application scope or the app scope(sys_scope) of a record not be changed or removed. This is platform expected behavior. This offers protection for your application artifacts to ensure that they are always associated to the proper application and that they have a unique name. For more info please check Namespace Identifier

You can however create a new application in correct scope and recreate tables, scripts, etc. and copy/paste the logic from your existing app/update set over to the new application record.

Source control integration didn't support global applications until the Orlando Release. From Paris onwards the global applications are can be linked to a GIT Repo. 

Vendor prefix is a unique identifier for a company and is randomly generated and assigned to an account. It is not advisable to change it. Vendor prefix is part of the Namespace identifier for an application & the system adds the namespace identifier to the front of application artifacts such as tables, scripts, and configuration records.

The identifier cannot be changed or removed from application artifacts to ensure that they are always associated to the proper application and that they have a unique name. In case there is a requirement to change the vendor prefix. Please reach out to ServiceNow Customer Support via HI.

• Login to your instance
• Navigate to Connections & Credentials > Credentials or go to [discovery_credentials.list]
• Click the "New" button and you will be asked what type of credential that you would like to create
• Choose "Basic auth", if you are using HTTPS as the network protocol or "SSH Private key" if you are using SSH
• Specify the username/password and complete all the other required fields
• Save the record
• Navigate to Studio and select the 'Import from Source Control' option or open an application in Studio and select Source Control > Link to Source Control option
• Now in the credential dropdown, you can see the newly created credential that will enable you to link your Source Control though your MID server.

When trying to use the 'Delete All Records' button on a scoped application table (sys_db_object), the following message is displayed and the records in the table are not deleted.

"Delete operation against '' from scope 'rhino.global' has been refused due to the table's cross-scope access policy"

Unfortunately, the 'Delete All Records' button will not work against scoped application tables do to the cross scoping security. Also, cross scope privilege records cannot be created using the Global scope as the Source Scope. The workaround to this limitation would be to write a custom script to delete all the records in the table OR use the Table Cleaner.

Delegated developers do not have access to Source Control. Admin access is required for the linking/importing an application with the Source Control Integration.

Role required: admin

By default, the following roles cannot be delegated.

• admin
• public
• nobody
• role_delegator, a user with the role_delegator role cannot delegate this role to other group members

Step to prevent roles from being delegated to users.

• Navigate to User Administration > Roles.
• Open the role.
• Configure the form to add the Grantable or Can delegate fields.
• Clear the checkbox for one or both of these fields. Click Update.