Office365 and SharePoint 2013 integration with System Center Orchestrator 2012 R2 and Service Manager 2012 R2

Author by Nathan Lasnoski

The SharePoint and Office365 platform is Microsoft's home for providing collaboration, portal, content, and enterprise communication.  I find that in Service Manager and automation projects we need to be able to interact with SharePoint in order to provide a seamless user experience and provide user interaction which feels complete.  In System Center 2012 R2 the Orchestrator integration activities have been updated to account for SharePoint 2013 and Office365.  I've spent some time testing these in preparation for some upcoming projects and found the configuration to be relatively easy and the integration with Service Manager to be a good point of emphasis.  I'll show below an example of how I've set this up in my environment.   The SharePoint site.  In my case I chose to build a SharePoint site for capturing self-service application installation, although it could be almost any kind of request you could think of.  Since SharePoint is used in end-to-end business processes, the integration with IT automation could even come much later in the process. 1. SharePoint Page

The SharePoint list configuration.  

You can see in the column listing I have fields I'm capturing for the request, as well as those I am hiding and logging to maintain state.  The principal state field is the SR_ID, which will match the SR_ID in Service Manager to allow for reconciliation between the Service Manager process and the SharePoint site. 5. List Configuration

Creating the SharePoint request.  The creation of the SharePoint request is pretty intuitive.  In browsing the site I can create my self-service application installation request and after submitting I see my requests, or all the requests for my team and myself.  This can be configured using SharePoint permissions easily.

2. SharePoint Request

The Orchestrator SharePoint configuration.  In the configuration of the Orchestrator connection for SharePoint I can see that I've selected a site collection, a username, a password, and the version of SharePoint (Office365 or on-premise).  The configuration allows me to use different accounts for different sites.

6. SharePoint Configuration

The workflow process.  The Orchestrator workflow process starts with a "Monitor Activity" which is allowing me to look for new requests, followed by a check for the existing SR (using the SR_ID on the SharePoint list item), then creating the Service Request, finally updating the SharePoint list item with the SR_ID.

4. Workflow

The list update.  The list is updated with the SR_ID which provides us the opportunity to keep the work items in sync between Service Manager and the SharePoint site.  I'd recommend this technique for any sync item, such as an announcement, calendar, etc.
7. Update List with SR ID  

This process allows me to consume requests from SharePoint, update them, then eventually close them when the overall process has been completed, or potentially even participate in a longer running workflow which includes a technical step part way through.   If you are doing a "Get List", then use a CAML query like this, where "SR329" is the ID of your Service Request, or is passed the SR_ID from the previous "Get Object": SR329   NOTE:  In testing it was found that AD-FS integrated Office365 sites have some authentication problems in the new integration pack.  This is not the case for SharePoint 2013 on-premise, or the Office365 without AD-FS.  Microsoft is aware of the issue at this point.   I hope this helps everyone to leverage their SharePoint environment in conjunction with Orchestrator 2012 R2 and Service Manager 2012 R2.   Nathan Lasnoski

Author

Nathan Lasnoski

Chief Technology Officer