Many customers launch their Citizen Developer (CD) programs with an initial focus on democratizing their Service Catalog. This is a great start for a budding citizen developer as most users are familiar with using the catalog. And due to the more structured and simple nature of a catalog item it is easier to learn the steps for creating an item, adding some variables, and assigning some simple approval and task-based workflows.
As the business process evolves, though, a catalog item may no longer be ideal, and the difference between the two types of “development” is insightful both for a workflow that may need to blossom into a separate application, as well as considering whether to use a catalog item in the first place.
Today we will try to understand the situations in which each of the two most popular technologies used by Citizen Developers, Catalog Items and Custom Apps, are appropriate and when it might be time to transition from one to the other.
What is the Service Catalog?
A quick primer on the Service Catalog. This is a foundational technology that has been on the platform since the early days. Most, if not all, employees will have used the Service Catalog (likely through the Employee Portal or a similar portal) for requesting IT support, ordering equipment, or opening and monitoring an HR case.
A Catalog Request is created when a user chooses a Catalog Item in the Service Catalog, fills out a form, and submits. Each Catalog Request will have one or many Request Items (these are what the Catalog Item generates). The Request Item is where the saved values for the item are stored. As the workflow progresses new tasks will be assigned to users and attached to the request item, and as approval steps occur these activities are attached as well.
Once all the approvals are made and all tasks are completed, the Request Item is also completed. Similarly, once all of the request items on a request (think of the request like a shopping cart) are completed then the entire request itself is marked completed and closed.
The catalog items are contained within a ServiceNow specific application called the Service Catalog. While it is flexible, it was built with this purpose in mind. When creating a catalog item you get a request, a request item and a flat list of the variables that the user inputted. These variables are stored in a separate table, making reporting on these values less efficient. And there is not a business unit specific data model that is molded to match the organization’s requirements.
Why start with a Catalog Item based process?
The Citizen Developer tools for Catalog Items at ServiceNow are great--intuitive, easy to use, and the efficiency means that beginners and experienced users alike can quickly start creating catalog items and configuring simple workflows.
It is a natural starting point for allowing individuals to begin managing their own content and processes with a low barrier to entry. And if you already have a manual process for this type of work in which business units are feeding ideas for new catalog requests to and changes to IT for implementation, it may be a great opportunity to transition the actual work from the IT developers to the teams that manage the catalogs or even the business units responsible for them.
Why not a Catalog Item based workflow?
Catalog Items are familiar and generally simple to create and maintain, so what are the scenarios where you might decide not to use it?
- Many service catalogs are ServiceNow out of the box and application-centric—think focused on ITSM or HR. This can cause two challenges if you start extending the catalog.
- Security: if your fulfillers are sharing a role (think “ITIL” or “HR”) then, by default, they will have access to all data in the application. This means members who become fulfillers by default have access to the data for all the other teams which share the scope and vice versa (e., the IT group will have access to the new team’s data too).
- Licensing: since most catalogs are focused on an existing licensed application the users of new catalog-based workflows may not have fulfiller license (unlike an ITIL or HR user) and may require additional licenses not meant for a smaller, lower volume org.
- However, if the flow is an addition within an existing application and user base of fulfillers it can be a good fit.
- The standard Catalog Item workflows are very useful and easy to configure but are, by design, quite simple. This may become limiting as the organization’s needs evolve and the flow becomes more complex.
When to use to a custom app
Here are a few things to look out for that may indicate that it is time to move beyond the Service Catalog into the world of a new custom application.
- Performance is slow—the special access controls you implemented to control access between the different teams using the common catalog request library is becoming slow and difficult to manage--especially if you have a lot of data in your request tables.
- The limits of reporting are becoming evident—you get questions like “what is the trend in this datapoint” or “show me an aggregated rollup based on a category variable” and you realize that there isn’t a very good answer.
- You need to integrate, for example hand a process off to another ServiceNow application (e.g. interact with Human Resources data) or you need to sync data with a third-party tool.
How to make the leap
The good news is that making the transition doesn’t have to be too difficult. A custom application differs in a few ways.
- It has its own data tables that can be modeled to suit the business units specific needs. This makes reporting, viewing, sharing, analyzing, integrating, archiving and controlling access so much simpler. Administrators for the custom application can be given full control while users and requesters have more limited access.
- Legacy data can be imported from third party sources or from existing service catalog requests.
- If the original catalog item was part of a scoped application, getting started could be as simple as opening the App Engine Studio and adding a new table by uploading a spreadsheet.
- Continue to use the service catalog—by replacing a Catalog Item with a similar-looking Record Producer a requester may not even realize that anything has changed.
- Start with a simple Flow Designer workflow and then feel free to flexibly grow and evolve your application with your business needs.
Conclusion
Enabling Citizen Developers is an important and valuable investment that organizations are making in increasing numbers. ServiceNow offers some excellent tools to enable those developers and the Service Catalog is a great entry to begin developing genuinely useful applications quickly. It is also a great way for a citizen developer to enhance their skills and it is a good idea to be ready when the time comes to make the next step from a simple request item to a custom application. Those using the App Engine Studio to get their organization on the path to citizen development also have the tools to make the switch when their needs expand.
| Catalog Item | Custom App |
Service Catalog | Catalog Item | Record Producer |
Reporting and Analytics | No | Yes |
App Specific Data Model | No | Yes |
Cross Business Unit Integrations | Limited+ | Yes |
3rd Party Integrations | No | Yes* |
* May require additional features or plugins
+ May read data from other apps or create tasks for other teams
