Attachments and Application Integration

Idea created by Chad Brown on Feb 26, 2018
    New Idea

    Good morning, EVERYONE!


    So, I'm back at full speed at work - and the theme this week is "Attachments and You". We will begin our tour this week with "Attachments and Application Integration."


    You may have noticed a plethora of comments/requests in the world of Application Integration on the community as of late. This indicates to me there are a larger number of people maturing their service catalog beyond the function of "Which Mouse or Keyboard do you want?" In our area, we are using the Service Catalog and Application Integration to provide the customer fewer "portal options" while expanding the Service Catalog at the same time.


    One of the areas of significant improvement, is the ability to pass an Attachment from the Catalog item into the child incident, problem, change, purchase order, etc. that Application Integration creates.


    USE CASES (i.e., what are these lunatics talking about?)


    Real Signatures Required

    We have a couple of instances where a copy of a signature is actually required (not a digital signature, but a digital rendering of a wet ink signature). In these instances the customer (requester) would be required to sign and attach a form. This would require an approval workflow, depending on the type of request, and spit out a Purchase Order or an incident on the other end - with that signature attached.

    1. The RUBBER stamp: This is not the euphemism where some just approves everything - but a request for an actual Rubber stamp of your signature. We receive and send a LOT of stuff, from paperwork, to toner, to computers. And, that all has to be signed for - either with the deliverer, or with the receiver. We are talking between 100 and 1000 items a week in some cases.
      • When the request is submitted, we would scrape the information, check the requester's department and site, and then populate a different Service Request based on that department's requirements for workflow, approvals, and assignment.
      • Instead of embedding layers of Conditional Statements with their own workflows - we find it is easier to manage the environment by embedding Application Integrations that point to other Service Requests. That way, when one department changes their approval process and requirements, it only impacts their portion of the request. 
    2. The Immutable Service Catalog Description: Using a single Service Request for multiple items that are related, a customer can be requesting a corporate credit card (requires a digital wet-ink signature), access to a Financial Application (no attachment required), and access to a 2nd Financial Application. When they select the corporate credit card, a Mandatory Attachment field populates and they would attach that digital wet-ink signature.
      • Application Integration would then populate the Incident (after approval) for the the Corporate Card, and pass through that attachment. Title of Incident: CC Request | {{Department}} | {{Requester}}
      • Application Integration would then Create Incident for access to Application One. Title of Incident {{Application 1}} Access Request | {{Requester}}{{Role}}
      • Application Integration would then Create Incident for access to Application Two. Title of Incident {{Application 2}} Access Request | {{Requester}} | {{Role}}


    Invoice Attachment

    We would like to roll out the Purchase Order application integration - but part of that process requires the attachment of the invoice. The PURCHASE ORDER module is not accessible by the Requester license, so we would offer a mock up as a Service Request.

    • So Application Integration creates the Purchase Order - as scripted; but....
      • Now, someone has to find the non-associated original request (application integration blindly creates the Purchase Order with no tie to its creation (ahem, grumble, grumble)).
      • They have pull off that attachment and attach it to the Purchase Order
      • There is incomplete TRUST the attached invoice is the actual invoice from the Original Intake Service Request. The only thing the Audit tracks is the name of the attachment - not the content. Financial departments relying on blind trust don't do well.
      • An attachment on a Mandatory Field in a Service Request CANNOT be deleted. So if Application Integration passed that through to the Purchase Order, there would be TRUST the attachment is the original (if I pull the passed through attachment off the Purchase Order and upload another one, that is in the audit log).


    Spreadsheets and Bulk Requests

    Our operations department uses the application to manage Call Queues, operations employee bonuses, and quality assurance on phone calls. When an adjustment needs to be made to call queues, employee bonuses (for mistakes or poor performance), or to log a monitor of a call, an ATTACHMENT is always required.


    Unfortunately, this means we have two call queue catalog requests, 11 requests concerning employee bonus adjustments, and three different requests involving call recordings. Now, if we could PASS through the MANDATORY attachment, this could be consolidated from 16 requests to three, and in turn, reduce the number of incorrect requests along the way (if the operations manager selects the wrong one of the 11 requests for employee bonuses, they have to redo it - workflows are immutable, and variables are locked in).

    • Call Queues: This a request to bulk move personnel from queue to another, but there are two different groups responsible, depending on the queue. The Service Request can only have one ASSIGNEE. They attach a spreadsheet of the personnel that need bulk moved.
      • Ideally which type of Queue Move would be selected, and Application Integration would create one of two incidents and assign that incident to the correct group responsible for the request.
      • The default group that is assigned the request is currently required to manually re-assign the request (before taking any actions that assign workflow-tasks to Incident Assignee) to the correct group.
    • Employee Bonuses: There are eleven types of circumstances and adjustments, and the output of which adjustments need to be made is attach a spreadsheet that shows the details.
      • Ideally they would select the conditions from drop downs and incidents would be created with the passed through attachment.
      • The customer wouldn't be stuck with Analysis paralysis of selecting the correct Service Request (made more difficult by the fact only five of them show on the main page - and newer managers forget to select show all, and think they only have five options).
      • The Titles of the Incidents would be easier to read (again, immutable and non-variable Service Request Titles), since Application Integration would create them as EB {{Type of Adjustment}} Adjustment for {{Circumstance}} | {{Requester}} | {{Year}} | {{Month}} and CUSTOM FIELDS for these get populated on the Incidents for Reporting (variables cannot be reported against in the application - not a complaint, the complexity of variables makes it inefficient to try to report against).
    • QA/Call Recordings: When completing the QA/Call Recordings, a recording is attached. Again, we want metrics on these things, and being able to change the Title, force data into custom fields (for reporting), and assign the Child Incident based on If/Then statements is crucial - but not as crucial as that attachment passing through.
    What problem will this feature solve?:
    "Let me explain... No, there is too much. Let me sum up." - Inigo Montoya.... Moving attachments from the intake form to the desired end point through application integration reduces processing time, opens modules that are hidden from the requester (why does only IT [i.e., licensed users] have access to purchase modules anyways?), allows far greater flexibility in a single form, improves/provides TRUST, reduces Requester confusion in the Service Catalog, reduces touches/labor (finding attachments and attaching them, manually re-assigning tickets to the correct group), and just makes everyone's life easier (except the Samanage developers - they have to hate us :P ).