What is the best design model for adding a configuration/settings page in custom app?

[jason_lau]

I've written a number of custom apps where I've stuffed custom app configuration settings in sys_properties table. What would be the more contemporary design model to store custom app settings in ServiceNow as I want to avoid using sys_properties for custom app settings. 

I would prefer to configure my custom apps to use something like app engine guided setup (guided_setup.do), or a single configuration page for settings (without using sys_properties). Can someone point me in the direction to documentation or a design model to do something like this?

Thanks!

Jason

[WORKFLOW-COWBOY]

What are your reasons to stop storing them in [sys_properties]?  I consider it a great place to store configuration settings for an app.  

For example

• Is it because of the experience of updating the values for a certain type of user?
• Is it because you have concerns about reloading the cache when values change?
• Is it because you need to walk a user through setting up initial values? 

Have you already considered making a System Properties module for your app?

Reference: https://docs.servicenow.com/bundle/sandiego-platform-administration/page/administer/reference-pages/...

A better example of this can be found in any system by editing the Navigation Module for "Service Portal -> Properties".  It creates a dynamic page based on the Category of the property. 

[jason_lau]

Hi Dale, 

Thank you for your response!

That's exactly what I do currently (sys_properties with module/category). I'd prefer to 'step up' my configuration pages with UI pages for the following reasons: 

1. there are sometimes I want application state but don't want to store them in sys_properties due to cache flush. 

2. in the past I've used sys_properties to store credentials, but I would rather have them stored as a credential set for consistency across other applications. 

3. I'm not wholly against using sys_properties.. that makes perfect sense for read-only values. But really what I'm trying to do is have a cleaner 'configuration page' module (ui page likely) which looks like single configuration page to the application admin but I have more flexibility where I store those configuration settings (table, sys_properties, credential set). 

I do think that sys_properties and categories have their place for smaller applications. I think for more polished custom apps I would like to explore options like guided setup or UI pages to clean up the user experience, and also to add some validation logic to the process (like test ui action to validate credentials and endpoint work). 

[WORKFLOW-COWBOY · Accepted solution]

That totally makes sense. 

There is an 'Ignore cache' checkbox on System Properties that you can check to prevent the cache flush when changing a property.  Probably want to consider this for minor system properties you are creating for custom apps. 

Regarding credentials - I would definitely advise keeping the stored in Connections & Credentials.  If you do use a system property, it should only be to store the sys_id of the Credential record you want to refer back to. 

For Guided Setup... it's not really documented on how to build your own, but it is very easy to deconstruct and build your own.  I have done it for several custom apps.  The first step is to edit the "Guided Setup" Application menu.  In the related list at the bottom for Navigation Modules, you'll see there are a few Nav Modules that are restricted to just the 'maint' role.  You can actually edit these so they are also accessible by the 'admin' role.  That will make them more useful to you for building your own Guided Setup pages.  Just make sure you are in the target App Scope for your app when creating the Guided Setup content. 

Using Guided Setup can be a good way for guiding an application admin for setting up initial system properties for an app. 

I would lean more towards using Guided Setup than a UI Page as I would consider it faster to setup and easier to maintain.  A custom UI Page is going to start going down a road of coding that may take longer and increase technical debt.  It might be harder to maintain in the long run for any of your admins or developers that might not be as familiar with the syntax that goes into a UI Page. 

[jason_lau]

Thanks Dale, 

Many nuggets of wisdom in your response, thank you!

-JL