Infographic accessibility descriptions

Narrative descriptions of SharePoint infographic posters provided for accessibility needs.

Last modified: March 09, 2015

Applies to: SharePoint Foundation 2013 | SharePoint Online | SharePoint Server 2013

The following sections each describe the contents of an infographics that are available for downloading at Apps for SharePoint Infographics. The narrative descriptions that follow are provided for those with accessibility requirements.

These sixteen SharePoint infographics are broken out into three general areas: Introductory material, App patterns, and Design choices.

In this article

Introduction

App patterns

Design choices

The goal of this infographic is to explain in a glimpse what SharePoint is from the web developer perspective. An infographic is a visual image such as a chart or diagram used to represent information or data.

You can use SharePoint to support your web development skills in the following ways:

  • Website kickstarter

  • Consumable services

  • App surface

  • Data store

Quadrant one: Website kickstarter

This green quadrant contains information on what SharePoint easily lets you create collaboration sites, intranets and public-facing websites. There are 3 tasks that you can achieve with SharePoint:

  • Create: Quickly create compelling and easy-to-use websites.

  • Share: Create and share intranets, public-sharing websites or team collaboration sites within your organization.

  • Customize: Use your web-authoring skills to customize and personalize your websites to suit your users’ needs using an intuitive web UI.

Quadrant two: Consumable services

The purple quadrant explains that you can use SharePoint services in your apps and websites. There are elements that list the SharePoint capabilities that contain the services you can use: 

  • Branding

  • Social computeing

  • Identity management

  • E-Discovery

  • Web content management (ECM)

  • Business intelligence (BI)

  • Records management and compliance

  • Mobile devices

  • Search

  • Business connectivty services (BCS)

  • Workflow

Quadrant three: App surface

The blue quadrant tells you that SharePoint provides endpoints that let you surface your apps by using cloud services and web technologies.

You can reach millions of customers by publishing your app to the Office Store or control access by publishing only to your corporate app catalog.

Quadrant four: Data store

The yellow quadrant shows you that you can use SharePoint as a data store. Store and access structured or unstructured data through a variety of options in SharePoint: 

  • Store relational data in lists, and files in libraries.

  • Use SharePoint lists and libraries to store the data that is accessed by your users and apps.

  • Access data from your pages and components using REST or one of the client object models, e.g., JavaScript.

The goal of this infographic is to explain in a glimpse why you should build apps for SharePoint. An infographic is a visual image such as a chart or diagram used to represent information or data.

You can build apps that integrate the best of the cloud and web with SharePoint. Here are top four reasons why you should build apps for SharePoint:

  • Familiar programming model

  • Flexible lifecycle

  • Access to SharePoint data and services

  • Flexible architecture

Familiar programming model

Apps are essentially web applications. If you know how to build a web application, then you know how to build an app for SharePoint. You can use any language, such as HTML, JavaScript, PHP, or .NET, and you can use your favorite web development tools, including Microsoft Visual Studio 2012, and a new web-based tool, "Napa" Office 365 Development Tools, to build app for SharePoint.

You can take advantage of the development tools that are designed specifically for the development of that tier instead of using general purpose tools. For example, you can have an app whose presentation logic is in HTML and JavaScript and runs on the client, whose business logic is in Microsoft .NET and runs in Windows Azure, and whose data is stored in SQL Azure. Or you can have an app that is written in PHP and has its data stored in MySQL.

Flexible lifecycle

Deploy and maintain your apps publicly on the new Office store, or internally on app catalog with flexibility and control.

  • Simple lifecycle –  Install, Uninstall

  • Publish to the store "SharePoint store"

  • Publish internally "App Catalog"

Access to SharePoint data and services

Provides apps with access to SharePoint data and services with a rich set of APIs.

Available services include workflows, taxonomy, business connectivity services, social networking, user profiles, and search.

List and library data is available programmatically.

A rich set of APIs include Windows phone and .NET client libraries, REST APIs, and a JaveScript library.

Flexible architecture

Take advantage of the flexible architecture to host your app’s business logic, data and user experience (UX) components. Your hosting options include SharePoint-hosting, auto-hosting (in the cloud using Windows Azure), and provider-hosting (using a remote server as host).

Data access options include using OAuth, cross-domain library authentication, or using remote event receivers.

Data storage options include SharePoint lists, data stores in Windows Azure, and data stores on a remote server.

The goal of this infographic is to explain in a glimpse what you can do with apps for SharePoint. An infographic is a visual image such as a chart or diagram used to represent information or data.

You can use apps for SharePoint to achieve the following goals:

  • Implement automation

  • Integrate internal and external components

  • Extend and customize SharePoint

  • Build stand-alone apps for Office and SharePoint

Implement automation

You can implement automation in a number of ways. Here are a few examples:

  • Automate predefined workflow steps

  • Create forms automatically

  • Automatically creates assembly & document generation

Integrate internal and external components

Here are examples of some of the ways you can integrate components both from within and from outside of SharePoint:

  • Display data from web

  • Create custom reports/dashboards

  • Access data from LOB (line of business) and enterprise data stores

Extend and customize SharePoint

There are a great many ways to customize and extend SharePoint. Here are a few examples:

  • Create custom search expressions

  • Provide user profiles, social and news feeds

  • Build custom branded UI

Build stand-alone apps for Office and SharePoint

You can build an unlimited array of custom stand-alone apps for Office and SharePoint. Here are just two examples:

  • Incubate search assist app. A company has a think tank that incubates new ideas. They have a SharePoint Online site which tracks a list of ideas. As part of idea research, they attach links to related topics from the Internet. To make searching a bit easier, they decide to build a SharePoint-hosted app that will search the Internet from within SharePoint. The app displays a search text box. When a query is entered, it calls the Bing Search API in the Azure Marketplace. The results are then listed below the search box. The user can click an item and choose to add it to a list of related links for a new idea. The app supports choosing which list to add the link to. The list is outside of the app.

  • Price change workflow app. A company wants to enable good collaboration on their products and pricing. The product prices (catalogue) need to be available to staff on the road. Also price changes must go through an approval workflow. The company plans to build an Azure Web app that stores the product prices to make it easier to access the prices by sales staff. An on-premise SharePoint site will be used to manage the workflow when a product manager initiates a price change that must be approved.

This infographic shows how common SharePoint tasks can be accomplished by using the new app model. The goal is to map known SharePoint concepts to features in the app model.

The diagram is grouped by task. For each task we describe how it can be accomplished using a traditional SharePoint solutions and compare that to accomplishing the same task in an app for SharePoint. 

Display external content on SharePoint pages

In a SharePoint solution, you can use a web part to include information from SharePoint.  The same data can be accessed in an app by using an App Part.

Web parts can run only on SharePoint, and can run with either currently logged in user permissions, or with elevated privileges.

App parts can run on a server external to SharePoint or in a browser and with the identity of the app or other specifically granted permissions. Some advantages of using app parts are that they can run in different domains than SharePoint, so performance won’t be impacted negatively.  Another advantage is that app parts are available both internally through an app catalog or published to the Microsoft SharePoint store.

Provide SharePoint notifications

When a notification needs to be sent to or from SharePoint, the SharePoint solutions model provides event and feature receivers. They require server-side code and cannot notify external systems without writing a custom component.

In an app, you are able to use remote event receivers and app event receivers.

Remote event receivers require client-side code, they can be used in both solutions and apps, and can be used to notify apps when external data changes.

App event receivers allow execution of code when apps are installed, uninstalled or upgraded.

Provide data access for SharePoint

The options you have when accessing SharePoint data using APIs in a traditional SharePoint solutions approach are the server-side object model, the client-side object model and OData.

The options you have when using an app are the client-side object model, REST APIs, OData and the cross-domain library.

Packaging and deployment

Packaging a SharePoint solution uses WSP files, which are compressed files containing configuration and content information.  These can sometimes to deploy across an entire SharePoint farm since they have to be installed in each SharePoint instance.

In an app, you can use the app catalog which makes the app available within an organization, or publish to the public Office store to make it publicly available or to sell it.

Use external data

To access data on external system, SharePoint solutions can use Business Connectivity Services with external content types.  External content types can only be installed at the farm level by an administrator.

An app can use app-scoped external content types which are installed within the app and don’t require interaction with the administrator.  They also have the ability to access OData sources.

Add custom pages and master pages

When customizing SharePoint solutions, you can create application pages or site pages. 

Application pages are hosted by SharePoint and are available to all sites on the server.  Application pages are the best option to run custom code.

Site pages are also hosted by SharePoint.  They are not recommended to include custom code because the code will break after customization using SharePoint Designer and any controls included must be registered on the safe controls list by the administrator.

Apps can use pages hosted on web sites other than SharePoint. Since these pages are hosted outside of SharePoint, they are available anywhere the app is installed.

This infographic shows you the different APIs available in SharePoint so that you can programmatically access different SharePoint services. An infographic is a visual image such as a chart or diagram used to represent information or data. This infographic shows a schematic view of how an app can access APIs provided through CSOM (Client-object model), JSOM (JavaScript Object Model), REST (Representational State Transfer), and OData (Open Data Protocol).

You can access the following services in SharePoint using one or more of the previous API models.

Search

Using CSOM, JSOM, or REST, you can build apps that can search pages, files, and people.

Web content management and publishing

Manage web content and publish to other sites. Using CSOM, JSOM, or REST, you can get or update navigation menus in web pages. You can also access publishing features to publish a SharePoint web site to an Internet location.

Business connectivity services

Access data from external systems – SAP, ERP, CRM and other data-driven applications. Using CSOM, JSON, or REST, you can create or remove subscriptions for event notifications based on an external database. You can also use OData to retrieve data from an external database through a BDC (Business Data Connectivity) model.

Workflow

Collaborate on documents and manage project tasks by implementing business processes on documents and items. Using CSOM or JSON you can access the Workflow services manager to customize and manage workflows.

Social

Help users connect to people and content that matter to them. Using CSOM, JSOM, or REST, you can manage user profiles. You can also manage what items or people a person follows, such as whether they follow specific documents, other people, or sites. Finally you can retrieve or update a person’s feed.

Enterprise content management

Manage unstructured information by using taxonomies, and also manage videos. Using CSOM or JSOM you can manage a taxonomy of terms used by SharePoint sites. You can also perform image rendition, upload videos, or get metadata about videos uploaded to SharePoint. 

Security

Manage SharePoint groups, roles and permissions. Using CSOM or JSOM you can add or remove users in SharePoint Groups. You can also manage permissions. Finally you can create roles and assign users to the roles.

Documents and lists

Enable team collaboration by sharing documents and lists between teams. Using CSOM or JSOM you can upload or retrieve files from a document library. Also you can create and manage lists. Using OData you can retrieve data from lists.

This graphic provides a few sentences of basic facts about SharePoint-hosted apps for SharePoint. It then provides a simple diagram to illustrate how the remote components of the app get authorized access to SharePoint data. It then provides bulleted lists, as follows:

  • Tools used to create such apps

  • Data storage options for such apps

  • Deployment tasks for such apps

  • Programming languages and SharePoint APIs that such apps can use

All of the information in the infographic can be found as text in the following documentation on the Office Dev Center:

This graphic provides a few sentences of basic facts about Windows Azure Acces Control Service (ACS), provider-hosted apps for SharePoint. It then provides a simple diagram to illustrate how the remote components of the app get authorized access to SharePoint data. It then provides bulleted lists, as follows:

  • Tools used to create such apps

  • Data storage options for such apps

  • Deployment tasks for such apps

  • Programming languages and SharePoint APIs that such apps can use

All of the information in the infographic can be found as text in the following documentation on the Office Dev Center:

This graphic provides a few sentences of basic facts about autohosted apps for SharePoint. It then provides a simple diagram to illustrate how the remote components of the app get authorized access to SharePoint data. It then provides bulleted lists, as follows:

  • Tools used to create such apps

  • Data storage options for such apps

  • Deployment tasks for such apps

  • Programming languages and SharePoint APIs that such apps can use

All of the information in the infographic can be found as text in the following documentation on the Office Dev Center:

This graphic provides a few sentences of basic facts about High-Trust, provider-hosted apps for SharePoint. It then provides a simple diagram to illustrate how the remote components of the app get authorized access to SharePoint data. It then provides bulleted lists, as follows:

  • Tools used to create such apps

  • Data storage options for such apps

  • Deployment tasks for such apps

  • Programming languages and SharePoint APIs that such apps can use

All of the information in the infographic can be found as text in the following documentation on the Office Dev Center:

This graphic provides a few sentences of basic facts about ross-domain, provider-hosted apps for SharePoint. It then provides a simple diagram to illustrate how the remote components of the app get authorized access to SharePoint data. It then provides bulleted lists, as follows:

  • Tools used to create such apps

  • Data storage options for such apps

  • Deployment tasks for such apps

  • Programming languages and SharePoint APIs that such apps can use

All of the information in the infographic can be found as text in the following documentation on the Office Dev Center:

The goal of this infographic is to explain in a glimpse the hosting options available to the developer to host the apps for SharePoint. An infographic is a visual image such as a chart or diagram used to represent information or data.

You can host your app code either in SharePoint, in the cloud, or both:

  • SharePoint hosting. Host your code in SharePoint to take advantage of client-side technologies and declarative workflows.

  • Cloud hosting. Tthere are two options for hosting your code in the cloud:

    • Autohosted. Deploy the app to SharePoint and let SharePoint deploy to Windows Azure for you.

    • Provider-hosted. You provide your own server hosting infrastructure and deploy to it.

Choose a hosting model based on your business scenario and needs

SharePoint hosted apps are best-suited for the following scenarios:

  • Individual or team productivity apps

  • Business process automation with low to medium complexity business rules

Autohosted apps are best-suited for the following scenarios:

  • Small, team collaboration apps

  • Large user base with small concurrent connections

Provider-hosted apps are best-suited for the following scenarios:

  • Large, robust Internet and enterprise-scale applications

  • Connecting existing sites to SharePoint

Weight the advantages and considerations for each option

Next, let’s consider the benefits of each hosting options as well as some of the trade-offs that each option entails.

Benefits

Considerations

SharePoint-hosted

  • Reuse common SharePoint artifacts

  • Automatic hosting in SharePoint

  • Native SharePoint UX

  • Run anywhere – on-premises or cloud

  • Uses JavaScript for custom visualizations and logic

  • Uses workflow for automation

  • No server-side code is allowed

  • App data stored in SharePoint lists

  • Slower patch cycle

Autohosted

  • Transparent provisioning of Windows Azure and SQL Azure components

  • No upfront investment for hosting and operations

  • Automatic load balancing

  • Still in beta

  • Not supported on-premises

  • Slower patch cycle

Provider-hosted

  • Can execute server-side code

  • Work with any existing web/on-premises servers

  • Use full power of Azure

  • Run anywhere – on-premises or cloud 

  • More developer responsibility

  • Requires upfront and on-going operational costs

The goal of this infographic is to provide a quick reference for the different types of apps supported by SharePoint. An infographic is a visual image such as a chart or diagram used to represent information or data.

App types quick reference

SharePoint-hosted

Autohosted

Provider-hosted

Host

SharePoint 2013

Windows Azure

Any host (Microsoft/non-Microsoft)

Deployment of components

All components deployed to SharePoint

Wrapper deployed to SharePoint Automatic deployment of components to Windows Azure

Wrapper deployed to SharePoint Manual deployment of components to host

Code/logic

Only client-side code App web created for app Declarative workflows for long-running, event-driven operations

Server and client-side code, any language or script

Server and client-side code, any language or script

Data storage

Lists, fields, and content types as data structures Data stored in content database

SQL Azure, SharePoint lists, others (consider latency)

Any: SQL, mySQL, Oracle, CSV, Access, FoxPro, DB2, SQLite

User experience

Integrate with core SharePoint experiences: app templates, style sheets, chrome controls

Full-screen/SharePoint-dialog box/app parts; Use SharePoint style sheets and chrome control from host web

Full-screen/SharePoint-dialog box/app parts; Use SharePoint style sheets and chrome control from host web

Authorization and authentication

Automatic

Windows Azure ACS provides authorization services

Developer responsibility: OAuth/cross-domain library

App permission management

Inherent

Uses SharePoint permissions from app Web; Stores App permissions in app storage

Developer responsibility

Multi-tenancy and tenant isolation

Inherent

Single tenancy; tenant isolation handled by Windows Azure

Developer responsibility

Infrastructure

No additional infrastructure

Windows Azure

Dedicated server provided by developer or IT

Usage model and licensing

No additional costs or licenses

Multiple licensing options: Microsoft-owned Windows; Azure account; Licensing through tenant; App catalog; SharePoint Store

Depends on hosting infrastructure

The goal of this infographic is to explain in a glimpse about data storage options in apps for SharePoint. An infographic is a visual image such as a chart or diagram used to represent information or data.

You can store your app and configuration data using any of the various storage options available:

Data

What kind of data is it?

Where can it be stored?

Application data

Data to and from an app

  • Remote server

  • Sharepoint list/document library

  • Windows Azure

Configuration data

App configuration settings and connection strings

  • Remote server

  • Sharepoint list/document library

  • App property bag

  • Windows Azure

The following table summarizes the advantages and disadvantages of the various data storage options:

Configuration option

Advantages

Disadvantages

App property bag

Lightweight; easy to use

No standard UI

Azure SQL database

  • Ideal for structured data

  • Relational database capabilities extend to cloud

  • Maintains data integrity

  • Requires middle layer

  • Does not support amount of data that exceeds the max supported by Azure SQL

Azure drive/blob

  • Suitable for unstructured data and large amounts of data

  • Add all certifications of Azure tables in blobs

For autohosted apps, each installation of the app provisions its own Windows Azure website

Azure tables

Fault-tolerant, ISO 27001 certified NoSQL key-value store; useful for apps that store large amounts of non-relational data

  • Autohosted apps do not provision out of the box

  • No server-side code for SharePoint-hosted apps; only client-side JavaScript

  • Provisions an isolated sub-web on a parent web

Azure queues

Create a backlog of work to process synchronously and pass messages from a Windows Azure web role to a Windows Azure worker role

  • Autohosted apps do not provision out of the box

  • No server-side code allowed for SharePoint-hosted apps; only client-side JavaScript

  • Provisions an isolated sub-web on a parent web

Remote servers

Independent; developers have full control; bring your own hosting server infrastructure

  • Developers will need to isolate tenants

  • Not recommended for app data storage

SharePoint list

Supports workflows and remote event receivers; uses standard UI; apply different permissions to lists

No transaction handling; not recommended for complex data relationships and large amounts of data

SharePoint doc library

Supports large amounts of data and provides advantages of SharePoint lists; can easily add binary data

No transaction handling; not recommended for complex data relationships

This infographic shows you the different technologies that you can use to incorporate external data into your app. An infographic is a visual image such as a chart or diagram used to represent information or data. The infographic has two main sections: a diagram and a scenarios section.

Diagram: Technologies involved

The diagram explains the technologies involved in accessing external data from your app. 

You can use the web proxy, external content types, or the cross-domain library with a custom proxy page to access external data. You can use the client object models and REST endpoints to consume the data.

Scenario one: David, web developer

David’s goal is to read small amounts of data from different sources. He wants to build a SharePoint-hosted app.

David chooses to use the web proxy, which can read data from up to 20 different domains, and each response can be up to 200 KB. He chooses the JavaScript client object model (JSOM) because it lets him use existing third-party libraries to process and manipulate data.

Scenario two: Mark, enterprise developer

Mark needs to perform CRUD operations against an LOB application. He also needs to sort and filter the data.

Mark, decides to use external content types because they easily expose data from the LOB application to SharePoint using the OData protocol. He also decides to use the REST endpoints because it can manipulate data using the standard REST query options $filter and $orderby.

Scenario three: Yvette, entrepreneurial developer

Yvette wants to query data from another service that her company owns. The external data is behind a firewall.

Yvette chooses the cross-domain library with a custom proxy page because she needs to perform the requests at the client level, so there’s no need to open ports on the firewall. She decides to use the JavaScript object model (JSOM) because she can use her current expertise in JavaScript.

This infographic shows you the different technologies that you can use to incorporate SharePoint data, such as documents and lists, into your app. An infographic is a visual image such as a chart or diagram used to represent information or data. The infographic has two main sections: a diagram and a scenarios section.

Diagram: Technologies involved

The diagram explains the technologies involved in accessing SharePoint data from your app. You can access the data with using a pull or push strategies.

A pull strategy means that there’s an action in the app that triggers the request to SharePoint. First you must decide whether to use OAuth or the cross-domain library, then you select between using the client object models or the REST endpoints.

A push strategy means that an event happens in SharePoint and the app must react to it. In this case you can use remote event receivers.

Scenario one: Paul, enterprise developer

Paul’s goal is to create a list item every day at 3:00 A.M. He also wants to create a SharePoint-hosted app.

Paul chooses OAuth, it’s a server-side protocol means the app can perform operations even if the users are not signed in. He chooses the .NET client object model because .NET developers can collaborate by using tools like Visual Studio.

Scenario two: Christine, web developer

Christine needs to read and display data from a list. She also needs to minimize the bandwidth used by her hosting provider, she is accustomed to consuming services on the web.

Christine, picks the cross-domain library because it’s a client-side technology, which means that less bandwidth is used in server requests. She decides to use the REST endpoints so there’s no need for her to learn a new language or object model.

Scenario three: Karen, entrepreneurial developer

Karen wants to run a process on her server when users add documents to a document library. She needs to minimize the number of requests between SharePoint and the app infrastructure.

Karen decides to use remote event receivers, which provide a push mechanism to avoid the need to continuously poll document libraries.

You can use SharePoint 2013 workflows to model business process and to automate business process steps. This document describes and infographic poster that illustrates many of the key features of SharePoint workflows for SharePoint 2013.

The workflow infographic is in three sections:

  • Workflow flowchart

  • What’s new in SharePoint 2013 workflows

  • Workflow architecture diagram

Section One: SharePoint Workflow flowchart

A flowchart depicts a sample workflow for a document approval process. This flowchart illustrates the progression of a document approval workflow, which is fully automated and which uses messaging APIs to interact with workflow actors like reviewers and approvers. Following is a description of the flow:

  1. When a document in the document control system is updated and its document status is set to "Ready for Review," the event launches the workflow.

  2. The workflow assigns a workflow task to predetermined document reviewers.

  3. The workflow also sends an email message to the reviewer to notify him or her that a review task is pending. (The workflow can also send reminder email messages if the reviewer fails to complete the task in a predetermined period of time.)

  4. The reviewer completes the task (that is, reviews the document) and either approves or rejects the document.

    1. If the reviewer rejects the document, the workflow sets the status to "Rejected".

    2. If the reviewer approves the document, the workflow sends a copy of the document to the document library and sets the status of the document to "Published.

Section Two: What’s New in SharePoint 2013 Workflows

No graphics. There is a narrative description of key new features in SharePoint 2013 workflows. Workflow in SharePoint 2013 have been significantly re-architected to better leverage Azure services, the cloud app model, and to fully optimize the new Windows Workflow Foundation, version 4. Following are some of the highlights of the new design:

  • A Fully declarative, designer-based workflow development environment provided by both Visual Studio and SharePoint Designer.

  • The workflow execution engine and required services are encapsulated in the Workflow Manager, which is located outside of SharePoint. SharePoint 2013 still contains the SharePoint 2010 workflow host so you can use Workflow Interop Service to invoke 2010 workflows from within 2013 workflows.

  • SharePoint workflow project types in Visual Studio 2012 to simplify creating workflow-based apps for SharePoint.

  • A custom action item type in Visual Studio 2012 to simplify creating custom actions.

  • New native workflow activities, as well as a new Workflow Services APIs.

Section Three: Workflow architecture diagram

There is a diagram of the underlying architecture of SharePoint 2013 workflows. These are the key visual elements:

There are two primary zones in the diagram: Architectural elements that are inside of SharePoint, and elements that live outside of SharePoint. The two zones are spearated by an access control layer, which uses the OAuth protocol for authentication and authorization of messaging that passes acros this boundary.

The key architectural element that are within SharePoint include the following:

  • SharePoint features like events, solutions, content, people and groups. Also included is the SharePoint 2010 workflow host (the legacy workflow execution engine) to support backward compatibility).

  • The Workflow Services object model (the REST OM)

  • The Workflow Services Manager, which includes services that manage messaging, subscriptions, deployment, workflow instances, and interop services.

  • Workflow service application proxy.

The key architectural elements that live outside of SharePoint are the Workflow Manager and the Windows Azure Service Bus. These two communicate with one another outside of the SharePoint boundary.

Workflows employ this architectural model using event messages and REST calls that cross the OAuth boundary. Following describes the flow of messaging and API calls.

  • Inside SharePoint, the Workflow Services Manager uses its messaging capabilities to pass event messages across to the Workflow Manager.

  • The Workflow Manager interacts with the Azure Service Bus to handle the workflow activities.

  • The Workflow Manager then communicates back across the barrier with SharePoint by using REST calls.

Inside of SharePoint itself, the Interop Service communicates with the SharePoint 2010 Workflow Host to execute 2010 workflows from within 2013 workflows.

Also inside of SharePoint, the SharePoint events are passed into the Workflow Services Manager to be handed over to the Workflow Manager.

For more information, see the following:

Show:
© 2015 Microsoft