Roles and Responsibilities

The different Roles in Tulip are the following:

• Honey User Role
• Audit Role
• Automation Developer
• Devops Lead
• Automation Admin
• Support Role
• Automation Agent Role
• Monitoring Role
• Generic Role

Honey User Role

The business user who get to experience the automation magic of Tulip has this role. So, they need not know the intricacies or the schematics of how things are developed. Accordingly, they have a limited set of views to only functionality they would be needing.

This is the typical view for a Honey User role.

As explained before, a user can experience the automation functionality of Tulip, based on the Profiles they are assigned with. The Profiles decide which services a user can have access to. Hence, a business user who is assigned with a Honey User role and a profile, gets to access the specific automation services. As a result of running automation services, the Reports of the Tasks created can be viewed by him.

Please find below the actions possible for a Honey User.

• Actions on automation services
• Tasks - View tasks asssigned to his Group and Claim
• View Reports - His own services and Support tasks
• Create Identities and assign to Bots of services he has access to
• Create Rules
• View Users
• Create PAT
• Customize Preferences

Audit Role

A user who is assigned this role, performs auditing, as the name suggests. Therefore in addition to the Honey User role's functionality, an Audit Role user can

• Experience the Audit Reports functionality

This the Tulip view for an Audit Role.

Note: The user with Audit Role, when assigned with the proper audit related profiles, can run specific automation services.

Automation Developer

The users with this role are the developers who are the constructing engineers of the Tulip platform as a whole. They have a wide range of responsibilities in order to create the buiding blocks of automation and assemble them to create a flawless experience for a user.

Basically, Automation Developer is the persona that

• Writes the code for the bots

He is solely responsible for creating

• [Bot templates] - To onboard the written bot code and to incubate the bot
• Bots - From Bot Templates to activate the bot and assigning profiles, identities, constants and input proposals
• Workflows - Using Workflow Designer and assigning profiles, constants and input poposals
• Rules - Using Rule Designer and assigning profiles
• Identities - Of different types and assigning to bots
• Forms - Using Proposal Designer for the user input tasks and other user interventions
• Automation agents - In case of onboarding a new Automation Agent in to Tulip

In the course of action, it is observed that this Automation Developer persona also defines

• Constants - Predefined values within the scope of the operation
• Input proposals - Inputs to be got from the user running the automation services

Click here to know how a developer performs all this.

What is to be noted is that users with the role of Automation Developer, have privileges to work on or view executions on bots/workflows which they create and which is applicable for their profile.

Note: It is not the responsibility of an Automation Developer to

• Schedule automation services in the Job Scheduler
• Work with Job Calendar
• Create Profiles
• Create Email Templates

The default view for an Automation Developer is the below.

DevOps Lead

This role is like a superset of the Automation Developer Role, wherein the privileges to work on or view executions extends beyond the scope of the owner. A DevOps Lead has access throughout the stack and his privileges enable him to override actions of individual Automation Developers.

A DevOps lead is a role which is primarily a collation of an Automation Developer's role and in addition a few others like,

• Creating Automation services - By onboarding Bots and Workflows and configuring Profiles and Input proposals
• Creating and configuring Profiles
• Creating Email templates
• Viewing Rule change history

He can also work with the

• Job Scheduler
• Job Calendar

Further, a DevOps Lead is the persona that is responsible for

• Package Management

Click here to know more on this and here to know how he does that.

Tulip's view for a DevOps Lead will be like the below.

Automation Admin

The highest superset of all roles, is naturally the Automation Admin, who has the overall control of the Tulip system. He can access each and every feature available in Tulip. He can view the overall status of tasks, reports, executions, etc.

He role-specific responsibilities include

• Job Scheduler
• Job Calendar
• Maintenance of Tasks
• Maintenance of Roles
• Maintenance of Tulip system
• Adding/disabling users to the system

Whenever some action in terms of maintenance is necessary from a support user, he has the power to put the Tulip system in maintenance, which would disable all other users from logging in except for support user. Automation Admin is the sole person responsible for blocking the support user login. This is performed under Tulip Maintenance.

Tulip's view for an Automation Admin will be like the below.

Support Role

One of the most important roles in the case of any platforms, a role which has weightage in terms of controlling most aspects of Tulip and the higher superset role, which can maintain Tulip - that is the Support Role. In a way, this role assumes equal status as an Automation Admin role, in the sense that this role has similar privileges. But when it comes to responsibilities, a Support user is more inclined towards maintenace related activites, ex: when there is an update to the system, or a issue in the system functioning.

A maximum part of the scope of a Support User's responsibilities lie under Tulip Maintenance, under headers applicable to this role.

Note: The Automation Admin sets Tulip in maintenance mode. This enables access to the Support user and disables access to every user of Tulip including the Automation Admin. Then after the Support user completes maintenance, he enables the Automation Admin role.

A support user has the following view of Tulip.

Automation Agent Role

This is a role which is not as such assigned to any user. Rather it is a role which is used by automation services or its components like bots or workflows to access certain functionalities.

The usage of this role is completely for internal invokations. The bots have to communicate with the Beekeeper of Tulip constantly for processing automation service requests. For such communications, the Automation Agent Role is assumed and processing is enabled. Because of this reason, no user is assigned with this role. And therefore, there is no view for this role.

Monitoring role

As the name suggests, this role is used for the purpose of monitoring the different features of Tulip. The Admin specific functionality is alone not enabled for users with this role.

As the role is for monitoring purposes, it is observed that this role has only read only views on all features of Tulip.

Generic role

This is a role very similar to Automation Agent role. While the Automation Agent Role is an internal invokations based role, used by Bots to communicate with the Tulip Beekeeper, Generic Role is used for external systems or Tools built on Tulip, to communicate with Tulip. When an external system like the SmartFinance wants to access Tulip's functionality, it uses the Generic user role to login to Tulip and extract the desired functionality.

The Generic role is a superset role, almost very similar to the Support role with a controlling access on the UI part of Tulip. Meaning, this role can access each and every UI component and control it. This role is not assigned to any user.