3101538 - General Information for Microsoft Teams Integration in SAP Cloud for Customer

You can find here different alternative customer can take for Microsoft Teams Integration in SAP Cloud for Customer. Additionally, please note that C4C is not storing any information at our end and  permission is similar to what groupware integration needs in order to sync appointment from C4C to Exchange server.

"Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental." 

 SAP Cloud for Customer.

Definition

• Application permission: Application permissions are used by apps that run without a signed-in user present. For example, apps that run as background services or daemons. Application permissions can only be consented by an administrator.

• Delegated permission: Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph. Some delegated permissions can be consented by non-administrative users, but some higher-privileged permissions require administrator consent.

Consent

• Application permission: The admin give access , on behalf of all the users who can use the app. Admin has to give consent once, irrespective of how many users are using the app. In case of no usage the consent expires in 30 days.

• Delegated permission: Every user has to give the consent, in fact if we have 1000 end user which is very likely, all of them have to give the consent. The consent flow has to be integrated to first usage of the feature, most likely to be the first creation or modification of appointment.

Token flow

• Application permission: App itself doesn't need a logged in user, can easily regenerate one, based on client id and secret, by the backend api.

• Delegated permission: User need to logon, the tokens then have to be stored some place safe, and a background job has to run using the user's token.To avoid multiple relogon, we need to store the refresh token and keep generating the auth token, whenever it expires.This also may need a background process that keep the refresh token alive, or we have to ask user to relogon.

Security by Azure

• Application permission: With App delegate, once consented,  Admin give access to app to create the appointment in anyone's calendar that is  part of the group of users assigned to app. The azure admin can restrict the no of user to access the application in many ways​.

       

        Admin can also have a different tenant for the app itself, with only the specific set of users, eg we have created only for employees dealing with unilever.

       

• Delegated permission: User gives permission to create appointment in his calendar only. All the azure admin changes are also reflected here.

User experience

• Application permission: Looks like a seamless process from end users perspective. His appointment created in the C4C, appears in the teams without him doing anything other than flip of the switch.

• Delegated permission: User needs to login into the teams app in the middle of meeting creation at least once, when he creates meeting. In case token gets invalidated, the background process will not create the team meeting, and we have to find a way to let the user know after post process to let the user know when he opens the appointment next time, that teams meeting was not created since the token was expired. The bulk creation of meeting will not work, unless until all the users have not logged in once and have a valid token. In case there is a meeting request using an api or data import, the MR will not be created, unless user has a valid session and token.

Can non C4C user can create the meeting, who has consent via our app ?

• Application permission: No since the api that we have formed, can only be access via a valid auth token which is given only if they have a valid SUT, which means that user has to be a valid C4C user.

• Delegated permission: No, need the valid token from end user.

Are we shipping client id and client secret exposed to client ?

• Application permission: No, the hosted solution  doesn't provide the client id and secret to any of the consuming tenant.

• Delegated permission: The token authentication and validation process is taken care by the end users and there IT department, they own the credentials

Sequence diagram

• Application permission: 

       

• Delegated permission:

       

Read and write calendars in all mailboxes

• Allows the app to create, read, update, and delete events of all calendars without a signed-in user. For example - when you create an appointment in C4C, the same is created / added automatically to the attendees calendar in background.

Manage all users’ Teams apps

• Allows the app to read, install, upgrade, and uninstall Teams apps for any user, without a signed-in user. For example - The SAP Teams app is automatically installed or added to the meetings that are synced from C4C as the new tab, which takes care of authentication and displaying the exact context.

Manage Teams apps for all chats

• Allows the app to read, install, upgrade, and uninstall Teams apps in any chat, without a signed-in user. Same as above but at chat level. During calls you can see an SAP team icon on right top and access the app directly via that icon.

Allow the Teams app to manage all tabs for all chats

• Allows a Teams app to read, install, upgrade, and uninstall all tabs for any chat, without a signed-in user. The SAP Teams app is automatically installed or added to the meetings that are synced from C4C as the new tab, which takes care of authentication and displaying the exact context.

KBA 3100512 - C4C MS Teams Integration FAQ

MS Teams, Application vrs delegated permission, C4C Teams. , KBA , LOD-CRM-TMS , Microsoft Teams Collaboration Channel , How To

SAP Cloud for Customer add-ins all versions ; SAP Cloud for Customer core applications all versions