So you're thinking about whether to build a custom business application on ServiceNow? 2/6

[Robert Maxwell]

This is the second article in the series. The previous article is here.

So how would ServiceNow improve the sort of process totally reliant on email? For starters, it could be done in phases, and I'll cover that first leap in this article.

But before I get to that, some housekeeping! There needs to be decisions made and structure in place to first of all allow and subsequently to govern and monitor citizen development, especially as the ServiceNow platform is such a major investment for an organisation. You should consider only allowing certain business units to pilot this type of venture.

Rules around what no/low code platform functionality can be leveraged by the business areas to build their apps, and definition of the rigour that will dictate the testing, promotion, maintenance and updates to the business apps will need to be developed and communicated. Considerations around impact to other deployed functionality, platform upgrades and patches, and even licensing also need to be front of mind for everyone from architecture practices, the ServiceNow support teams, configuration managers and those with financial delegations and responsibilities for ServiceNow.   

Step one in ServiceNow itself, with Guided Application Creator walking you through, could simply be creation of a basic Task based table with a rudimentary state (or status) model (e.g. New, On hold, In progress, Completed), some categories to suit your particular use case, and then the real brains of the operation, an Inbound Email Flow - so all the emails bound for that inbox literally build the queue for you in ServiceNow. Note that you'll have to get the emails redirected to ServiceNow by whoever looks after email flow within your organisation for this to function.

Matching the email address of the sender to the data in the User table in ServiceNow in the flow will make it easy to see any other emails sent in by the same person - here is where you could get some insight on how often or how recently this person might have come to your team for support, and thus potentially even identify a trend or see the emergence of an issue.

You can even respond to the received emails from directly within ServiceNow, and keep track of these for reference and recording. Immediately you'd see reward from having the ability to produce a report with no more than a couple of clicks to see the status or any other grouping of your entire queue, and even get an idea of how quickly things are being responded to or completed. Step one, Done!

Now the rubber hits the road. Time to start the process which will lead to the business area actually being able to use it anger. The fact that this functionality has been built by the business area, the citizen developer, as opposed to a traditional development team shouldn't change to a great extent the process driving the Software Development Life Cycle (SDLC) - apart from more of a critical eye from those charged with testing and review of the app that’s been built and those responsible for Application Lifecycle Management (ALM) within the organisation. Critical here, and at all times when citizen development practices are active, is communication with, and some high level conceptual training for the citizen developers about how the SDLC and ALM processes operate end to end. Knowledge like this for the citizen developers will give perspective and warn of any potential impacts of what they do across the ServiceNow ecosystem. Then get the training for the business users underway and start the countdown to the go-live.