Duff & Phelps realized the need to convert paper documents to PDF docs for long term digital storage and to save on legacy paper storage costs.  Automation as well as a recorded process for easy end user use was needed, so Dave Maseman, Desktop Manager at Duff & Phelps created a request offering in Service Manager for users that was accessible via the Cireson Portal.

Dave Maseman is the first winner of the Innovation Award for System Center Service Manager by Cireson. Described below the the solution summary and description for use in your own organization.


Solution Summary
To reduce impact on the firms staff and the environment, Duff & Phelps (D&P) decided to redesign their long term documentation retention process to eliminate waste. Leveraging System Center 2012 and the Cireson Portal, D&P designed a automated process enabling users to submit requests for document conversion to PDF format for long term retention, streamlining the process

The solution delivered several key benefits to the organization, including:

  • Dramatic reduction in human associated with document archival
  • Automated capture of electronic approvals
  • Elimination of legacy paper storage costs
  • Automatic escalation when errors in the process are detected

Perhaps most importantly, the solution represents a strategic process automation win, clearly demonstrating the role of IT as a strategic asset, eliminating waste and driving efficiency throughout the business.

Solution Description
Below is a detailed description of the solution, as shared by the
We needed a way to convert paper documents to PDF docs for long term digital storage and to save on legacy paper storage costs that we were paying to Iron Mountain. We also wanted some automation as well as some “checks and balances” along the way to make it as easy as possible for the end users and also give us a record of the process. In order to facilitate this process, I created a request offering in Service Manager that our users would see via the Cireson Portal where the end user enters and submits:

The 5 digit product code

  • Project Name
  • Manager name in charge of project (Query results in Active Directory to show users with manager attribute)
  • Number of files to be converted
  • Description of the documents
  • An acknowledgement about document retention and that the original documents will be destroyed once they are uploaded to digital storage.

Upon submitting these items, a new service request (SR) is submitted in Service Manager that starts a chain of manual activities and Orchestrator Runbooks:

1. A manual activity is created to notify the users in our production room that ‘X’ number of documents (pulled from request offering) relating to project number ‘X’ (5 digit project code from request) are waiting to be scanned.

a. The production team member then brings the documents to a Xerox scanner in any of our offices and selects a preprogrammed task on the scanner that was setup for this process. They enter the 5 digit project code at the prompt on the scanner and then scan all the documents.
b. The scanner creates a folder with the 5 digit project code in a preset location on our NetApp SAN and creates all the pdf files in the folder.
c. The person who scanned the documents now marks their manual activity as completed via the SCSM Exchange connector or Cireson Portal.

2. An Orchestrator runbook is now initiated to compare the scanned data to what we have in our project database:

a. Gets the specified manager from Active Directory that was selected in the request offering query.
b. Adds permissions for the manager to the folder containing the scanned documents.
c. Runs a “Query Database” activity based on the 5 digit project number If there is no match in the SQL database, the SR is closed as failed with the results of the query added to the SR. A user would follow up with the requestor.
d. Assuming there is a project match, a compare activity looks at the manager email address in the SR and make sure it matches the UPN from the “Get User” activity. If email doesn’t match, SR is marked as failed and reason is added to the ticket. User would follow up with the requestor.
e. If match is successful, a “create related object” is initiated that creates a new manual activity with the manager as the “implementer” and the description has the location of the files that were created in step 1b above.

3. The manager clicks the link in the notification he received for the new manual activity and takes a look at the pdf files that were created via the scanner above. If everything looks correct, he marks his activity completed.

a. If something is not correct, he can “fail” the activity and it will create a “problem ticket” that will be followed up on by the appropriate staff member.

4. At this point, another Runbook is kicked off that will grab the folder and PDF files from the original location and move them to the permanent project folder. The project folder location was obtained earlier via a SQL query in the runbook in step 2b.

5. After the successful move of all the files above, another manual activity goes in progress with the original scan requester as implementer. Their activity is to check the actual project folder and make sure that all of their documents came over and are correct. They can mark their activity complete through the Exchange connector or the Cireson Portal.

6. Assuming step 5 is marked completed by the original requestor, another manual activity goes out to the person who physically scanned the documents. The activity has all of the project information as well as the manager and requestors name. The activity directs the user to go ahead and destroy the original documents per our document policy.

7. Once the documents are destroyed and the activity is marked as completed, the original SR is marked as completed and it’s closed.


  • There is decision logic at every approval step so that if something is not correct and an activity is not approved, a problem ticket is automatically created for the appropriate person to follow up.
  • All the activities are created in a template that Orchestrator updates throughout the process.