Tasks – Part 1: Tasks Overview

  • Comments 11
  • Likes

This blog post is intended for developers and people doing advanced customizations in Service Manager.

Tasks are a key component of the Service Manager user experience and infrastructure.  There are two different kinds of tasks:

  • Console Tasks
  • Tasks (we usually call these “Runtime Tasks” to differentiate them from Console Tasks)

All the links that you see on the right hand side of the console or forms are Console Tasks.


Console Tasks run locally on the same computer as the console and run under the security context of the user that the console is running as.  They also run in the same process as the Service Manager console (Microsoft.EnterpriseManagement.ServiceManager.UI.Console.exe).

Runtime Tasks are tasks which are submitted to the Management Server to process.  These are typically used in background workflows, but occasionally can be submitted when a user clicks on a Console Task.  An example of this is the Synchronize Now task in the Connectors view. 


When the user clicks on the Console Task, the code that runs actually submits a request to run a Runtime Task to the management server which then triggers a synchronization job for the selected connector.

Both Console Tasks and Runtime Tasks are defined in management packs.  Console Tasks are defined as MP elements <ConsoleTask> and Runtime Tasks are defined as <Tasks>.

You can control which Console Tasks and Runtime Tasks are available for users to run using User Roles.


Security footnote intended primarily for developers: We don’t control security access by granting/denying visibility to console tasks.  Permission to do things is centrally controlled at the Data Access Service.   Because a Console Task runs under the security context of the console user and runs locally on the console computer, the user could write a custom program that directly accessed the Data Access Service that does the same thing as the Console Task.  If the user has permission to do the action at the Data Access Service then he will be allowed to do it using the custom program (even if the Console Task is not granted that does the equivalent action).  Granting/denying visibility to console tasks is really only intended to improve the user experience by removing actions that you don’t want people to run or that you know they can’t do anyways.  Runtime Tasks on the other hand are secured at the Data Access Service because they run in an elevated security context and on the central management server.  If you do not grant someone access to a Runtime Task, they will not be able to submit it.  Further, the user must have permission to submit the Runtime Task against the target object.

So – in summary:

  Console Tasks Runtime Tasks
Management Pack XML Element <ConsoleTask> <Task>
Run Location Console Management Server
Security Context Console user Run As Account defined per task
User Roles Scoped for hide/show purposes only Scoped for security purposes
Shown in Console? Yes, in the Tasks pane of the main console or in forms windows. No. They are typically run by background workflows.  In some rare cases, a Console Task may submit a request to run a Runtime Task.
Display Output in Console? Optionally, yes, output is shown immediately when the task runs.  In some cases it makes sense to show output like a Ping task.  In  other cases it doesn’t make sense like a Remote Desktop task which has no output to show. Since these tasks typically run in the background as part of workflows, you can see the results of the tasks in various places in the UI, especially in the Workflows Status view.
Can Create in the Console? Yes, in the Tasks view using the Create Task wizard. No.

Next in this series, we’ll dive into Console Tasks in more detail.

Tasks Part 2 – Custom Console Tasks for Create, Edit, Delete

Tasks - Part 3: Command Line Console Tasks

Tasks – Part 1: Tasks Overview

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi, Travis

    could you please show us how to create user roles programatically?



  • Hi, Travis

    could you please show us how to create user roles programatically?


  • @Archana - Can you please provide an example of what you would like to do?

  • Hi, Travis

    Could you please show how to get the incident, that is active in moment, when I run some task.

    I want to create task that changes state of current incident to the "Resolved" or some other state. So, how I can get this incident, that is current?

    In other words, how can I programatically get the instance of Incident class, that is selected in view AllIncients, when I click on my custom task?

    Sorry for my bad English =)



  • @!A.Zaviruha - I dont have time to provide a detailed answer on this right now but you can see an example of how to do this in this blog post and related source code example:


  • Thanks!

  • Hi Travis,

    A client has the requirement that users be able to assign incidents to themselves, but nothing else until their name is against it. Is this possible using permissions to hide/show tasks? Or is it something that is not possible at all?


  • @Matt_Hall88 - Unfortunately I don't think that is possible with the SCSM security model as is.

  • Thanks Travis, I didn't think it was, just wanted to check!