Loop-back in Application Integration

Idea created by Chad Brown on Oct 5, 2017
    New Idea
    • Matthew Coley
    • Chad Brown

    Are there plans to allow loop-back through Application Integration. Here is our scenario:


    We have designed a complex nesting of Service Catalog items for the Onboarding process; however there is a hurdle.



    We have a Single Catalog item that sends a multitude of TASKS around the world, but ultimately only one group owns the Request (Service Desk), and their is NO VISIBILITY of the process to the customer. By NO VISIBILITY, I mean the customer cannot view the Workflow, see what tasks are pending, who is responsible for them, and the like. We are not asking for that to be visible - that creates more problems than it solves.


    PROBLEM 1: Groups throughout the company that use Samanage on a daily basis for Incident, Problem, and Change management get dozens if not hundreds of emails a week. They are not NOTICING task assignment emails. They have to leave the INCIDENT MANAGEMENT section of the application and go to the DASHBOARD to find Tasks.

    PROBLEM 2: The REPORTS section of the application does not track Tasks. Some of the IT departments (Operations) have metrics to measure the amount of work requested of their departments. A Single Service Request with 30 tasks shows as a SINGLE UNIT of work, and it was WORK assigned to and done by the SERVICE DESK only.

    PROBLEM 3: You cannot assign a PRIORITY to a task. All TASKS are priority neutral. If a group needs to prioritize their workload, nothing from an INDEX screen can show this TASK should take priority over anything else. The best you can do is add language to the task and hope someone sees it (back to problem 1).



    Our new process looks to take these TASKS and output them into INCIDENTS or CATALOG ITEMS of their own. Now, instead of a TASK being generated, the API Integration would spawn a CATALOG ITEM (for a well defined process, like setting up voicemail, creating a specific type of NTID for the Network, Issuing a Building Access Badge, etc...), or it would spawn an INCIDENT for more variable requests (like adding to one-off security groups, granting access to network shares, etc... where the request varies from the norm for that JOB TITLE).


    WHY DO IT THIS WAY 1?: This allows teams that frequently work in the application to be focused in a single screen for all Incidents and Service Requests. This is an efficiency and reliability issue.

    WHY DO IT THIS WAY 2?: Each Unit of work is spawned as its own INCIDENT. That means it shows up in reports, managers and Management can  get a better handle on TIME to RESOLUTION for specific units of work. Try digging out the time to resolution of a TASK in a catalog item (requires you spend a lot of time going through the Audit and manually calculating time based on Business Hours - it is horrible).

    WHY DO IT THIS WAY 3?: It gives SOME visibility to the customer. They know the onboarding requires Telecommunications, Systems Engineering, Networking, Service Desk, Finance, Physical Security, Information Security, and Human Resources to complete tasks (the child-incidents are spawned in the original requester's name).

    WHY DO IT THIS WAY 4?: This allows department managers to look at work assigned to their teams in one location. You can open a QUEUE and manage it cleanly. You can be agile and know if person A is out, to shunt that work to person B or C. Or if site A is down due to severe weather, shunt their work to site B or C.

    WHY DO IT THIS WAY 5?: Designing catalog items that spawn other items allows you to scaled up (and back as necessary). You design the "individual units of work" and then point to these when you design your Service Offerings. You don't have to recreate the wheel each and every time you build a new service. This means we could do the same thing for SERVER BUILDS, SITE DEPLOYMENT, OFFBOARDING, APPLICATION DEPLOYMENT, OFFICE MOVES, SITE BUILDOUT, DEPARTMENT MOVES, (there are dozens more)...



    The API Integration is "Fire and Forget". Meaning, once the Incident or Catalog Item is spawned, it is going to move on. It isn't waiting for feedback of that object being resolved. If the LINEAR workflow requires someone to be a member of a specific Security Group before an Application can be set up on their system, there is no AUTOMATED way of knowing the Request to add them to that group is done.


    We are looking for something in the Workflow that Pauses until the spawned event reaches the desired state (CONTINUE on RESOLUTION) or (CONTINUE on CLOSED).

    What problem will this feature solve?:
    This would allow us to build a modular service catalog that scales throughout the enterprise.It allows groups that need to report metrics about workload, time to resolution, etc... far more accurately. It allows an efficient streamlining of operations. YES there is more work in setting up the catalog; however, tripling the time of three people to quarter the time of 100 people is a good trade.