โ01-15-2021 08:22 AM
[Dec 22, 2020] Mike Power (CRM Enterprise Architect at American University) posted:
Good afternoon all,
We did a brief POC with Workbot for MS Teams recently, and may build some recipes with it but our infrastructure group has governance concerns.
Iโm curious what others do with Workbot for MS Teams (or potentially other applications since the need for governances is probably the same). Questions like:
Weโre pretty new to this space, so Iโd appreciate any thoughts/gotchas on starting to use Workbot as an organization.
Thank you!
โ01-15-2021 08:26 AM
[Dec 22, 2020] Jayesh Shah (CSM at Workato) replied:
Hi Mike,
Great questions. Please see comments inline:
1. Whatโs your governance process for regulating what can be done with the Workbot connector, managing PII, etc?
The Governance model for Workbot is similar to other recipes.
The Workbot connections are managed similar to other application connections. The best practice is to create an identity specifically for integration - Integration System User (ISU) and then limit the entitlements/scopes to what is needed for the integration use cases. The connection credentials will generally be created by the Office365 admin and either they can create the connection or someone who has the privileges can create it on the Workato platform.
The recipes around the Workbot are managed using the fine role based access mechanisms through the Team capability. This allows for controlling who can develop, maintain, operate and deploy the recipes, etc..
The overall model will be dependent on the use cases - can you share more on the scenarios and the specifics around PII? In general the interactions are private between the Bot and the user invoking the Bot command. There are few options depending on the needs:
(1) If PII is being provided - then use Direct Message channel rather than a shared channel.
(2) Provide URL link to the actual application if specific PII is to be viewed or updated - this way the interaction is within the application.
2. Do you check the box when you log in to โconsent on behalf of the organizationโ, which I believe means the connector can be disconnected/re-connected by anyone, not just the Office365 admin.
The connection should be managed by the Office365 admin. The Workbot is generally retrieving data or making updates in a set of source applications. These actions are generally done as the Integration User Identity (ISU). For approval scenarios where the permissions are controlled by the source applications - Workato supports the notion of a Verified user or a Personal connection - the user who is performing the approval action needs to authenticate with the application and the action is performed using the identity of the user performing the approval action in Workbot rather then the ISU identity. More at: https://docs.workato.com/workbot-for-teams/workbot-latebinding.html
3. How do you manage what commands get published so itโs not overwhelming? Or do you just do things by channel?
There is an overall aspect of defining the use cases and the overall user experience. The user experience is a key part of the overall Workbot recipe design and determining whether the commands should be part of standard Workbot or a custom Workbot - which allows for Workbots for a specific set of tasks/activities for e.g. HR Bot, Service Bot, etc... More at: https://docs.workato.com/workbot-for-teams/workbot-custom-bots.html
Hope this helps.
โ01-15-2021 08:27 AM
[Jan 14, 2021] Mike Power (CRM Enterprise Architect at American University) replied:
Thanks for the response Jayesh.
When you say the best practice is to create a separate integration user to set up the connection, which we do with our other connections, but for Teams it must be an O365 admin. I canโt imagine weโd want to set up another O365 admin account purely for Workbot? Or is this what other clients do?
The Use Case is this:
But thenโฆ does this PII just remain in that Teams chat forever? Is there a way to clean it up after a certain amount of time?
โ01-15-2021 08:29 AM
[Jan 14, 2021] Jayesh Shah (CSM at Workato) replied:
Hi Mike,
Responses inline below:
Mike: When you say the best practice is to create a separate integration user to set up the connection, which we do with our other connections, but for Teams it must be an O365 admin. I canโt imagine weโd want to set up another O365 admin account purely for Workbot? Or is this what other clients do?
Jayesh: Our recommendation is to have a different user identity - this will allow for tracking changes/updates that are made by the user through the O365 GUI vs. through the MS Teams Bot automations.
Mike: The Use Case is this:
But thenโฆ does this PII just remain in that Teams chat forever? Is there a way to clean it up after a certain amount of time?
Jayesh: One aspect to consider is to have a custom Workbot for this specific use case.
You can then limit access to the support team that needs it. More on custom Workbot at: https://docs.workato.com/workbot-for-teams/workbot-custom-bots.html
I believe the data would remain in Teams chat forever - not sure if MS Teams has some options that would allow for archiving or deletion of the chat content. One aspect to consider is to either remove or overwrite the conversation with the PII from MS Teams - may require some additional research on this. May be other member may have suggestions on options on this.
โ02-18-2021 12:58 AM
Hey Mike,
PM for Workbot here!
You donโt necessarily have to create an O365 admin as the integration user per se. You can have the admin assign the Global Administrator role to the integration user for the installation of Workbot, then remove the role after installation. Checking โConsent on behalf of organizationโ is optional. Just have to bear in mind that for reconnections, youโll have to grant Global Administrator to the integration user again.
AFAIK Teams does have a delete message ability, weโre looking to support it some time this year. For now, DMs seem to be the way forward for messages with PII.