Marq enables admins to divide users into more manageable chunks, or “groups”.
Marq enables admins to divide users into more manageable chunks, or “groups”. Within Marq, there is only one type of user group, but there are two ways in which a user can belong to a group: membership and primary membership. A user can belong to any number of groups, but each user can only have one group to which they are a primary member. We’ll refer to this group as the user’s primary group, but remember the group isn’t primary by itself, just in relation to that user. Learn more about groups.
A user’s primary group will typically represent their business unit within the organization (department, region, etc.). Ordinary membership, on the other hand, might represent participation in a cross-functional team that requires collaboration. Because users can only have one primary group, they are used for settings and configurations that require an “either-or” decision. For example, Tommy’s license should either be billed to Product or Engineering, not both. If it should be billed to Product, set “Product” as his primary group.
Some “additive” features in Marq apply to all members, not just primary members. An example of this is project sharing. So, for example, if Tommy is in 5 groups, he will have access to all of the projects that are shared with those 5 groups.
Important Note: All primary members of a group are ordinary members also, meaning primary members will be shared on projects that are shared with their group in addition to inheriting the group’s settings.
Currently, the features that are managed by groups are project sharing (all members) and licenses (primary members). As more features are brought to the group level in the future, they will either affect all users or primary users only depending on the use case.
Group admins can be useful for multiple reasons, but the most common are (1) to reduce the workload on the central IT team and (2) to put licensing power in the hands of those that pay for the licenses (via bill-back), and (3) to give managers and teams more control and visibility, so that they don’t always need to reach out to IT.
While group admin may be very helpful for some accounts, it may not be as useful for others. Group admin is probably only helpful for accounts that do some of their user management manually. SCIM, Google provisioning, or other automated provisioning tools are great compliments to group admin as long as some piece is done manually; usually, this manual piece is license management. In SCIM, for example, you can create all users but leave their license attribute undefined. This will allow group admins to control who has a license while removing the burden of manually creating and deleting users when employees join or leave the company.
Currently, group admins have the ability to perform the following functions on users in their group(s):
- View users
- Manage licenses
- Transfer projects (when delicensing or deleting a user)
- Edit user profiles
- Delete users
- Export a CSV of users
Because group admins cannot create users or add them to their groups yet (this must be done at the account level), we recommend provisioning users with view-only permission (free) for all employees that may need access and assigning them to the correct groups. Group admins will then have visibility into all of their users so that they can respond quickly when a user needs a license instead of waiting on IT to provision a user before they do so.
There are several methods by which this can be done at the account level:
Method |
Pros |
Cons |
SCIM Provisioning |
Fast Automatic Supports groups |
Requires SCIM capabilities |
Bulk CSV upload (admin panel) |
Fast Supports groups |
Requires maintenance |
Manual
|
Easy No setup required |
Slower Requires maintenance |
- Account Owners and Team Admins can assign any number of group admins to a group.
- Group Admins see a new link to the Team pages when they log in.
- Group admins will be directed to a limited Users Page only showing only the users in their group(s).
When a user in the group requests a license, the group admin will receive a notification. Team admins can turn off license request notifications for users that are assigned a group admin.
Some organizations prefer to expense the cost of Marq back to the appropriate cost centers within their company rather than expensing the whole cost to IT.
When it comes to splitting the bill, there are a couple of options; both require that users be assigned the correct primary group.
-
Upfront Purchase
Each business unit submits a purchase order for Marq licenses to the appropriate internal team (e.g., finance). Once approved, those licenses are reserved within Marq for the users in that OU.
To accomplish this, Team Admins can use license allotments (beta) to reserve a specified number of licenses for each group to use. When an allotment is specified on a group, group admins can manage those licenses as they see fit.
A user’s license is consumed from the user’s primary group. So, a group’s license allotment represents the number of primary members with licenses that the group can hold at one time.
An important thing to note is that while group admins cannot exceed their own license allotments, it is possible for a group to exceed their license allotment if licensed users are added to the group through an automated process like SCIM, Google Group/OU import, or CSV upload. To resolve this conflict, admins must manually delicense users or adjust the license allotments accordingly.
When it comes time to run expenses, admins can refer to the license allotments dialog on the Users page to know how much to expense to each department. In the upfront purchase scenario, the allotments should match their purchase orders mentioned above.
2. Need-based
The other option is for companies to bill their business units based on how many of the account's licenses they end up using. In this scenario, business units are free to use as many of the accounts licenses as are needed. When it comes time to expense licenses to cost centers, admins use the number of licenses that groups are using. This can also be found in the license allotments dialog (pictured above).
This method doesn’t require the use of license allotments. However, unlike the upfront model in which businesses can cover the cost of spare licenses, the as-needed model requires a central sponsor (possibly IT) to cover spare licenses.