A task that is not an incident, problem, change, request, or project

[Eric K3]

We have a sizable number of groups/departments/users who need to use SN tasks in an unorthodox manner. For example, some itil users create an incident to document that they verify weekly/monthly backups on their systems. Other groups create incidents for doing routine maintenance. Still other departments use an incident to note that they performed routine observation/support on a device.

The problem is these groups/users are keeping these incidents open, sometimes for weeks, months, even indefinitely. They do this so that they can set a date in the followup field and sort their task lists to see what incident they have to work on on that particular day/week. They use the same incident to document that they performed the backup/maintenance/support. This, of course, is not what an incident is supposed to be and this greatly skews our performance metrics. It is even problematic in trying to implement SLAs that are meaningful.

My question is: What have others done to solve a problem like this? Do I simply create a new application by extending the task table and call it "Routine Tasks?" I am thinking a new application that extends [task] is the way to go so that tasks from this new application will show up on the My Work and My Groups Work modules.

Also, if there is a need to perform a daily/weekly task, how could I make SN create and assign a task on a regular basis? For example, can SN create a task every Monday morning with a short description of "Verify weekly backup on System XYZ" and assign it to the backup group?

[Matthew Glenn]

We solved this issue in the exact manner that you described. A new application extended from Task. Working well so far.

Regarding creating a regularly scheduled task, you should be able to simply click on the 'Scheduled Job' module and then 'New'. Then use the Interceptor option 'Automatically generate something....'. You'll need to create a template for each individual task that you want to have created but that shouldn't be too hard.

More info can be found here   http://wiki.servicenow.com/index.php?title=Creating_a_Scheduled_Job#Scheduling_Entity_Generation

[Uncle Rob]

Robert's First Law of Platform Development:   Maintain Purity of Intent

Your Incident table should be used to store Incidents.   You should move non-incident activity into dedicated task types.   This keeps their own data elements separated and provides a *much* cleaner overview of any given team's workload.   The more one cludges all this together in one table, the less people care when you say "my team has 5 people and 250 open Incidents".   Because honestly, that could mean anything.

Now, the one thing working against turning that solution around quickly is CreateNow.   CreateNow licensing means new custom task types are new apps, and therefore come at a $35/user month (list, but nobody pays list) price.   The price does not scale per app, but is only applied once per user.  

Some may balk at that price.   To those, I ask if its not worth paying to manage the process properly, its not worth putting in the tool in *any* capacity.

[Eric K3]

Here is the response I received from our Sr. Solution Consultant...

============================================

Yes, you will need a "Platform Runtime" (formerly CreateNow) license to build a custom application that extends task or any other table (since you own other service management applications).   So pricing will depend on how many Fulfiller users you intend to have use your custom application.

Here is the verbiage from our policy:

Platform Runtime (previously named "CreateNow")

Platform Runtime is a subscribed right for a customer to deploy in production applications developed on the ServiceNow Platform. These customer-developed applications can address any use case across the enterprise.

3.1 Packaging

Access to the ServiceNow Platform to develop applications does not require "for fee" use rights. Deployment of a developed application in production requires Platform Runtime use rights for every Fulfiller user of that application.

While custom application templates are included with the platform, it is important to note that they are not supported or warranted by ServiceNow, but rather provided to the customer as a sample starting point if they wish to use them.

3.2

Pricing and Licensing

Platform Runtime is subscribed to in an unlimited application model. Customer Fulfiller users with Platform Runtime use rights may use in production any number of custom applications. Platform Runtime is packaged this way because one of the core missions of ServiceNow pricing and packaging is to drive adoption of the platform across all parts of the enterprise, with the ultimate objective of every employee becoming a Fulfiller of the platform.

Development Usage Rights

In all customer scenarios, it is important to understand the contractual rights granted to the customer. Customers that have subscribed to Platform Runtime and to a ServiceNow-built suite or application are granted rights to copy and re-purpose the applications subscribed to as the starting point for a custom application. If the customer has only subscribed users for Platform Runtime and does not have use rights for any other ServiceNow Suite or application, the customer may only extend from the task table.

In addition to the applications delivered in the respective suites/applications, customers are provided the capabilities of the platform to configure and administer the applications delivered in the respective suites/applications. Subscribed users are NOT granted rights to deploy custom applications (non-ServiceNow-built applications) in production unless they have Platform Runtime Fulfiller use rights. Platform services are defined in the ServiceNow Product Overview document as the ServiceNow Platform.

===================================================

[Brad Tilton · Accepted solution]

Hi Eric,

You could also take a look at the ticket table. It's a table extended from task that isn't used for anything OOB. I've used that in the past for custom things like this. Also, some of what you described sounds like standard changes or requests.