Scoped applications and technical debt

[Chaz_]

Hi,

When considering implementing scoped apps, I would like to know whether these can have the potential to cause performance issues and increase technical debt.

In one scenario, a plugin will be installed in its own scope and discovers network information. Yet, it will also introduce between 10-20 fields on the Incident, Problem and Change tables respectively and quite a large number across CMDB table, but remain part of its scope. 

Would the above scenario be a cause for concern from a technical debt and performance point of view? More specifically, the not all incidents will have this information populated. They would be when discovery information comes in. Would this affect the load time of the forms to display/hide a tab, and would it affect searches as the extra fields would be blank across the majority of incidents.

Thanks in advance for your input.

Chaz.

[Ryan Duce · Accepted solution]

Fields remain fields in the database even if they are part of an application scope. Any business logic, security rules, UI policies, filters etc must still be evaluated on them. So the large number of fields on the incident / problem tables won't cause any less of a performance impact because they are scoped, and in fact are likely to cause more as cross-scope privileges must also be evaluated on them since they sit on a global table. (Someone more technical than me might be able to confirm this guesstimate).

Scoped apps should be considered a way to manage technical debt and better understand / protect cross-scope interactions. The technical debt and performance overhead is still present.

What are the additional fields on the incident / problem tables designed to do? Is it all information that's specific to the incident / problem or can it be siphoned off to its own table that sits entirely within the app's scope? If you are worried about usability, you can set up the table to be dot-walkable to the incident / problem it references and build database views specific to your app to get the required UI / table joins. If you're worried about licensing custom tables you can consider extending exempt tables.

[SaschaWildgrube]

I challenge the use of the term "technical debt" in this context. If a feature is build and provides value to a customer - it is NOT "technical debt".

I recommend reading this: https://www.servicenow.com/community/developer-articles/technical-debt-management/ta-p/3265989

[Chaz_]

Thanks Ryan. Very helpful.

The extra fields on the ITSM tables are discovered fields for network devices showing their state and error logs/messages. Would be good to understand why scoped apps are built in this way where they affect tables in the global scope? I would have also thought it would be better to create the discovery information table within the scoped app and link to the ITSM tables.

[Ryan Duce]

The use case for a scoped field on a global table is when you want a scoped app to extend baseline functionality in a completely protected way. One common use case I run across all the time is a Jira integration to ServiceNow incidents. A scoped field, x_vendorprefix_jira_id, is often added that only the scoped app may write to and is used as the coalesce value onto the Jira issue.

It sounds like you're downloading an app from the Store, is that right? If not, then I'd take the opportunity to tweak the design slightly. This app sounds like it's trying to cater for the requirement that network engineers have ready access to the information they need to resolve the incident from the incident form itself.

However, it's far better to put discovery information into the already-provided CMDB tables and examine the related CI from the ITSM task record (Service Graph connectors do this in a way that complies with the ServiceNow data model). The advantages here are:

• Multiple data sources can update the CI with clear precedence and priority rules
• Data relevant to one type of CI (e.g. firewall) isn't tracked on the incident even when it's not necessary, or when the incident is about another type of CI.
• When the CMDB data is updated, it's kept in the CI's audit history and doesn't become out-of-date. It can then be used in problem RCA / change success analysis etc.

For error messages / logs, it's better to use a relationship + related list that appears contextually at the bottom of the incident table only when it's relevant. This also gives you inline filtering and sorting from the related list in the incident so it's far more useful. You can add related lists on scoped tables to a global form in a similar way as you can add scoped fields.