# Roles, Invitations, and Permissions

One of the most powerful (and patented) aspects of iLiv All-In is its system of Roles and Invitations.

Together these provide the levels of abstraction and flexibility that allow composers to do their best thinking about how the organization delivers value. They also seemlessly manage permissions, which are critical for data integrity and security.

# Roles

Roles are descriptors of people, reflecting what skills, talents, and interests they have.

Most Roles in Performer are created by users, but there are two built in Roles:

• Project Admin
• Group Admin

Both Project Admins and Group Admins are empowered to create Roles, but where they are created, as well as their scope, are different.

In Performer, a Project Admin can create a Role anytime. These ad hoc Roles belong to only that Project; even if they have the same label as another Role in another Project, those two Roles are not connected. If you are running a one-off Project, or if you need to add a Role to a Composed Project that only applies to that one instance, an ad hoc Role is the way to go.

In Composer, a Group Admin can also create a Role anytime. Composed Roles are more powerful than ad hoc Roles, because when used across Compositions and Composed Projects, the multiple instances of the Role are connected.

The first time a Role defined in Composer is instantied in a real Project in Performer, it is automatically given a type by the system. We say: the Role is typed. Each Typed Role is unique from all other Typed Roles, and, everytime you use a Types Role it is related through its type with all other used of the same Role.

Composed Roles (Typed Roles) allow the system to track and compare the use of those Roles across many Projects, as well as the performance of individuals in those Roles across many Projects (very useful for optimizations and reports).

# Invitations

Invitations are how people get permissions and take responsibilities on a Project. Groups can be invited to a Role too.

The power of Roles and Invitations:

• In iLiv's world, you never assign someone to a Task. You assign a Role or Roles to a Timeline, Task, Milestone, or To-do. Then you invite a person or Group to accept the Role.

• Not only is this a nicer way to do business, it's also a more powerful way to engage people in collective effort. Assigning a Task would be a one-way command. Sending and accepting an Invitation is a two-way contract, and a more polite and engaging way to get epople working together.

• An uninvited or unaccepted Role Invitation is not a show-stopper. Use it as a placeholder for someone who will take responsibility in the future. You can get the team going without requiring that all performers are on board.

• When someone leaves a Role, their future responsibilities do not walk out the door with them. They remain with the Role. The history of that person's work on the Project also remains, for the person who will accept the Role next to see and learn from. Onboarding and offboarding are much more streamlined, and things are much less likely to fall through the cracks.

# Permissions

Beyond its purpose of managing workflows and responsibilities, the Role and Invitation system performs the critical behind-the-scenes function of setting and removing permissions.

The All-In system tracks and stores a detailed history of every invitation, broken down into discreet steps. Some steps trigger the granting of permissions to read or write specific pieces of data. Other steps revoke previously granted permissions.