cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Bot governance

jessica-lie
Workato employee
Workato employee

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

  1. Whatโ€™s your governance process for regulating what can be done with the Workbot connector, managing PII, etc?
  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.
  3. 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!

6 REPLIES 6

jessica-lie
Workato employee
Workato employee

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

jessica-lie
Workato employee
Workato employee

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

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

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.