topic Re: Bot governance in Workato Pros Discussion Board

Bot governance

jessica-lie — Fri, 15 Jan 2021 16:22:46 GMT

[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:

What’s your governance process for regulating what can be done with the Workbot connector, managing PII, etc?
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.
How do you manage what commands get published so it’s not overwhelming? Or do you just do things by channel?

We’re pretty new to this space, so I’d appreciate any thoughts/gotchas on starting to use Workbot as an organization.

Thank you!

Re: Bot governance

jessica-lie — Fri, 15 Jan 2021 16:26:29 GMT

[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.

Re: Bot governance

jessica-lie — Fri, 15 Jan 2021 16:27:27 GMT

[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:

Certain Help Desk users benefit from getting a series of data points from 2-3 different systems upon initially triaging a problem. This data includes their name and date of birth, which can be sensitive.
At first I had thought about a particular Team in MS Teams that would be dedicated for Helpdesk, though it could be a direct message I suppose.

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?

Re: Bot governance

jessica-lie — Fri, 15 Jan 2021 16:29:42 GMT

[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:

Certain Help Desk users benefit from getting a series of data points from 2-3 different systems upon initially triaging a problem. This data includes their name and date of birth, which can be sensitive.
At first I had thought about a particular Team in MS Teams that would be dedicated for Helpdesk, though it could be a direct message I suppose.

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.

Re: Bot governance

jan-donyada — Thu, 18 Feb 2021 08:58:03 GMT

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.

Re: Bot governance

mroldanvega — Fri, 26 Feb 2021 20:33:06 GMT

We have a dedicated service account for the connection. Our Office365 Admin is able to temporarilly elevate its permissions to perform the consent, then change it back to non-admin. The admin does this for us only one time during the setup.

We have a single bot, and yes the commands are getting a bit long. I dont think we are ready for custom bots yet. Probably soon. However, one of the things we do is check AD/Okta group membership for the user who is running the bot command to see if they are allowed to run it.
I.e. in each bot recipe we capture the user who is running the bot, we call a callable recipe that checks if this user is a member of an AD group that we define for this purpose (or reuse a group if already exist). If the user is not a member we stop the command and reply to the user with some kind of "not authorized" message.
Hope this helps.

Re: Bot governance

jessica-lie — Sat, 27 Feb 2021 19:13:34 GMT

Hey Mike Power !

Tagging you back into the loop, so you are kept up-to-date with more of the brilliant information your peers have provided 🙂

Ported this conversation from the previous platform. Hope the new answers are of help to you!