Managing Your Virtual Agent’s Lifecycle
Protecting a virtual agent’s development, testing, and production environments is critical in any organization. With the recent introduction of fine-grained access control and dialog skill versioning, Watson Assistant makes it easy for you to deploy changes to your virtual agent without any downtime. This post will explain the concepts behind these two features and how they work together in seamless lifecycle management.
Assistants and Skills
Watson Assistant separates your virtual agent into the component you deploy, the assistant, from the component that controls the logic and responses, the skill. The assistant is what you reference from your own application (unless you use built-in integrations which also use the assistant). A skill is added to the assistant. And the skill is where the day-to-day development of intents, entities, dialog responses and logic occurs.
Versioning
When you create and begin editing your dialog skill, you are working in its ‘development’ version. When ready to deploy, you save what is in development as a new version within the skill. This creates an immutable snapshot of your skill. Any updates you make going forward, are made to the development version of your dialog skill; you will not impact the snapshot you created.
Your different environments in Watson Assistant are controlled with different assistants pointing to different versions of the same skill. We recommend creating a development assistant, a testing assistant, and a production assistant. To move your changes from development to testing to production, all you have to do is have the corresponding assistant change to the new skill version that’s ready for promotion. Easy and zero downtime!
Fine-Grained Access Control
If multiple people will be working on your virtual assistant, it’s important to protect your different environments from inadvertent and undesired changes. Collaboration in Watson Assistant starts by inviting users to your instance and granting them the access roles associated with different permissions. Roles are assigned in the IBM Cloud console (accessible via the Watson Assistant tooling account menu).
The available service roles are:
Reader: Can open assistants and skills but may not make any edits
Writer: Can open and edit any assistants and skills
Manager: Can open and edit any assistants and skills, view conversation logs
A user’s role can be set for the entire instance — permissions are inherited to all skills and assistants in the instance — or for a specific assistant or skill.
If you wish to control which skills and assistants a user can edit, we recommend giving your invited user the Reader role at the instance level, and either the Writer or Manager role for the specific assistant or skill they will need to edit. Alternatively, you can opt not to give an instance-level role and only assign assistant- or skill-specific roles, in which case your invited user would not see any assistants and skills in the tooling except those that you have explicitly selected.
Note: At least one platform role at the instance level is required. The Viewer role is recommended.
Protecting your environments
Development, testing, and production environments are protected by choosing the appropriate roles for the right assistants and skills. To provide an idea of recommended assignments, let’s look at an example of a company that has four collaborators: Two developers who update intents, entities, and dialog but only one will be allowed access to end-user conversation logs. One QA engineer who tests the chatbot changes before deployment and a DevOps staff member in charge of deploying to production.
In this example, there will be three assistants for each environment and a single skill. All four of our users will be given the viewer platform role at the instance level so they can open the tooling and see the instance. They will also be given the Reader role at the instance level so they can see all the skills and assistants in the instance.
The developer with permission to see logs will be given the Manager role for the skill and the Manager role for the development assistant. The developer without logs access permission will be given the Writer role for these same resources.
The QA engineer will be given the Manager role for the testing assistant. and the DevOps staff member will be given the Manager role for the production assistant.
Because the developers do not have rights to edit the production or testing assistants, those environments are protected from changes by the developers as long as each of the assistants is pointing to a saved version of the skill. Saved versions are immutable, and as long as an assistant is pointing to a saved version, the version cannot be deleted. And since QA and DevOps do not have permission to the skill, the development environment is protected. The QA engineer and the DevOps team member will only be able to update their corresponding assistant which includes changing the skill version their assistant points to.
Instance-level role permissions are inherited by all skills and assistants so resource-level assignments should always be of higher access.
Versioning+ Access Control = Easy Lifecycle Management
Ready to collaborate? Just open up Watson Assistant and the IBM Cloud console to get started. You will find additional details in the versioning and access control documentation.
Oscar Kafati is an AI and machine learning product manager at IBM and has been developing Watson AI products since 2014.
