FujiForty - Must Have App Publishing Checklist

I've been developing ServiceNow applications since 2006. Over that time I've seen the process, and even the definition of what an application is, greatly change. The largest of these changes came with Fuji and the introduction of the application store. I spent the past year dedicated to working with ISVs building apps on Fuji EA and GA releases. I realized that I have a pretty consistent and structured checklist that I follow for building and reviewing applications, although it's all been an auto-pilot process in my head. Some may say I’m giving out my secrets, but since CAVUCode is all about empowering vendors so they can manage their own applications, I’ll spill the beans.

 

Instance requirements

If you are interested in building a certified application and publishing it to the ServiceNow store, you’ll need to start with requesting a vendor development instance through the Technology Partner Program. This links the instance, and all file components to your vendor account. If you are only interested in creating an update set to share, you can use an existing instance or one of the free personal developer instances.


Development

Once you have the initial personas, stories, and general architecture defined, it's time to start developing a new scoped application. I generally start from a scratch template.

 

Backing up

Before we get too far, it's worth mentioning the obvious. Sure ServiceNow has industry leading availability, but if you've been around long enough you've encountered that unexpected zboot (instance reset) from a co-worker that was sure there was nothing going on in the instance. I recommend occasionally creating an update set from your app and exporting the xml file to be stored as your recovery file if needed. This is especially important if you are doing development or concept work in one of the free personal developer instance that will self-destruct after 10 days of inactivity.

 

Think about domains

Domain separation is commonly used by MSPs and other large companies as a way to control different data processing and visibility for child companies/clients/departments. You should at least be aware of this type of configuration so you can determine whether you should consider the changes needed to make your application domain-aware.

 

Debug logging property

The new verbose logging options in Fuji are extremely helpful and much more efficient than managing your own logging class, so be sure to leverage it and properly create (add choices for verbosity levels) and expose the property to your customer admins. Exposing the property means creating an application property category and a module linking to the category for easy access. The wiki also defines a property to control the logging destination (db or file). I don’t see any value in adding this since would confuse most users and admins need events written to the database in order to view them in most cases.

I initially set the value of the debug verbosity property to “debug” so it outputs everything for faster troubleshooting. When writing server-side scripts, I’ll also enable system debugging to direct the log output to the screen, which saves time having to go look at the log table. If you don’t have console debugging enabled, be sure to check the app and system logs during development. I see a lot of cases where an app is causing errors but they go unnoticed because the test case is working correctly.

 

Review app file requirements for new tables

It always sucks to realize after you created a table and spent time developing scripts that you should have created the table as an application file extension. Sure there are ways to promote a table from base to an app file extension but I’ve always found it to be buggy, so I’d rather start from scratch.

 

Set initial application access

For newly created tables, set the initial application access properties based on the known use-cases. These may change throughout the development and testing process, just start with what you think they should be to provide more realistic development testing. 

 

Set reference cascade rules

An often forgotten or unknown configuration. Reference fields store a pointer to a record in another table. By default, if you delete the remote record the pointer will still exist as an orphaned reference, just a lonely guid. You may notice this occasionally when the reference icon displays next to a reference field but there’s no display value and the icon won’t load the reference record. In most cases this is not an ideal configuration so be sure to review and set the reference cascade rules in the dictionary for each reference field created.

 

Review transform map choice actions 

Most ISV integrations have a data import component which would require an import set and transform map. When mapping to a choice or reference field you need to understand the result of importing a value that doesn’t have a matching choice or reference value. The default action is to create a new choice or reference record with the new value being imported. This is usually not the preferred behavior since it’s rare to have an external system import be the master source of this data, although in some cases it is valid. The other options are ignore (ignore the value and import the rest of the record), or reject (reject the entire record). This comes up frequently during certification review as well so know what the settings are and be ready to justify them. 

Since the transform map interface doesn’t really make it easy to identify choice and reference fields I use a helper background script that I can run against all maps in an application. 

 

Review security

The application and table creation process will help generate the initial role(s), module access, and table security access control rules. This is a great start, but may not always be the best security for your application data. You may also need to manually create rules for UI pages, processors, and client callable script includes.

 

Review file protection policies

This is a critical topic that needs to be properly evaluated to understand the trade off between building stable software and allowing field customizations. By default all records are set to have no protection policy, which means customers have the ability to inspect and modify core application files. There are times when this is valid, but in many cases you’ll want to protect the record by limiting read or write access.

 

Check-in all workflows and custom activities

You’d quickly find problems in testing if you forget this step but it’s a good time to review all activities and workflow definitions as well as the activity pinning properties.

 

CREATE APP FILES AND Build demo data

For app file extension tables, be sure the source records are correct and have the correct file protection policy, then create and include any demo data you might want to provide to your customers.

 

Review global scope dependencies

Some applications require changes to core global scope or other scope objects that cannot be captured in your application payload. An example is changing application access control on a core table to allow configurations or write access. These changes must be documented for testers and customers to configure prior to installing your application.

 

Do THE ToDos

I have a habit of commenting scripts with //TODO if I need to comeback to clean something up or add additional code. At this point I do a quick search of all application component sys_update_xml records for “TODO” in the payload to see if there’s anything I forgot to do.

 

Quick review of app components

For a quick review I view the list of application files, grouped by class to see if there are any obvious files that shouldn’t be there, or something that might be missing. This can easily happen if you are frequently switching between application scopes during your development work. This is also a very helpful view when it comes time to document the application components for the certification submission.

 

Cover your tracks

Depending on who you were logged in as during the development of records you might want to scrub the created by and updated by information in your app files. I recommend not using admin or developer names, and prefer to use the name of the vendor so it’s very clear who created or updated the record.


User Acceptance Testing

At this point we should have our release MVP and be ready to start some acceptance testing.

 

Logging level    

Set the logging level to “info” just in case you forgot before publishing the application. No need to ship an app with a flood of debug logs right out of the gate.

 

Test documentation

Depending on who's doing the testing, you may need to provide some documentation on application setup, usage, and troubleshooting. You’ll also need all of this for the certification submission so it’s a good time to get started while you are waiting for feedback from the test team. 

 

Test instance

Developers will guarantee that 100% of the time their application works…well at least it does in their environment. There’s a lot of factors that can come into play when testing an application in a non-development instance so it’s critical to do this before publishing or sharing your application with customers.

If you are going to submit the application for certification and publishing in the store, you should use the option to “publish to another internal instance”. This will allow you to replicate the deployment process of the store as well as validate the file protection policies and upgrade options. If you aren’t interested in the store then distribution through an update set should be good enough. If you've gone through multiple iterations in the test instance, it might be worth testing again in a clean instance (zbooted) since this is what the certification team and your customers will do on the initial install.

 

Domain Testing

If you have access to a domain separated instance and you included domain support in your design, then you should add domain testing as well.

 

Testing of application configurations

In addition to all of the persona use-case test scenarios, you should verify file protection policies (not available if using update sets), application access (especially to global and other app scope components), all security components. This is where you’d run into problems if you forgot to document or perform the “pre-install” configuration changes to global objects.

 

Review logs

One more chance to review app and system logs to see if your app is generating any errors. 


Prepare for certification

Now that you’ve gone through testing and have addressed the issues and feedback, you’re ready to start the certification submission.


Call for backup

If this all seems a bit overwhelming or you're still having trouble with the basics, give us a shout. We can help with any or all of the process as well as provide guidance and training to get you to the point where you can be a self-supported ServiceNow store vendor.