K2 Five Communication Flow

This conceptual diagram illustrates typical communication and authentication flow when users interact with K2 through various channels, such as SmartForms, K2 APIs, and K2 Workspace, as well as how underlying services such as Internet Information Services (IIS), the K2 Server, SQL server, and line-of-business (LOB) platforms communicate.

Considerations

• This diagram illustrates the high-level communication flows and supported authentication protocols between commonly used components in a K2 Five environment. It does not depict network topology requirements for communication flows, including flows between on-premises on online components.
• Best practice is to install the K2 server and the K2 site on the same server, for optimal performance. They are shown as separate servers in this diagram only to better illustrate communication flow.
• You must configure the SharePoint remote event receiver endpoint (the SP15EventService) as an SSL-secured and accessible on the internet when building event-based processes for SharePoint Online. For more information see Preparing SharePoint Online in the Installation and Configuration Guide.
• While the SP15EventService connects to K2 in the context of the application pool account, the request contains the originating user from SharePoint, and the workflow instance is started as the originating user.
• You can configure Instances of Service Types/Brokers to use different methods for authenticating against the target system. Not all authentication modes may be supported by all service types, and sometimes systems may be limited to a specific mode only, for example some online systems can only use OAuth.
• You can use this Service Type with an on-prem Exchange server as well.
• The K2 Package and Deployment tool uses Windows authentication by default, but you can manually configure it to use an Azure AD identity as detailed in KB002069: How to configure K2 Package and Deployment to authenticate an AAD User in K2 Five.