This article assumes you understand how groups work.
Group sharing is a mechanism by which you can share groups of locks with other accounts. This allows users in the shared-to accounts to access those locks in some specified way. In concept group sharing is similar to sharing a folder from a computer, except every share is specific to a shared-to account.
Group sharing is accessed via Groups / Edit / Sharing. To manage group sharing you require "Modify Group Sharing" authorization.
When you share a group you specify separate shared group role and a shared group member role that each determine the full scope of access available to users in the shared-to account. The user's access permissions will be determined by the intersection of a users's permission in the shared-to account, and the permissions you make available in the share.
A receiving account will be able to see all shared groups and locks, in addition to the account name of the sharing account. Such information will also be recorded in audit trails, and this audit information will remain visible on a shared-to account even after you have revoked a share.
A sharing account will be able to see all activity on shared locks by keys in the shared-to account, and the key's identifying information. Such activity will remain visible on the sharing account even after un-sharing for as long as a key continues to hold authorization(s) for the shared locks.
A sharing account will be able to see all keys authorized to access shared locks, and is permitted to blacklist such keys. The blacklist will only apply to locks owned by the sharing account.
To manage group shares you require "Modify Group Sharing" authorization. To share to an account, the account owner must have granted you access, but you do not require any other permissions on the account.
You may only share groups of type Department, and Administrative. Only locks in Administrative groups will be visible to shared-to accounts.
To add a group share:
To revoke a share, access Groups / Edit / Shares, select the share to revoke, then click Delete.
When you revoke a group share, all activities relating to that group on the shared-to account will in effect become 'deleted'. This includes shared locks that have been re-grouped, and Permissions based on the shared group. All keys carrying authorizations for shared locks will be revoked at the next key sync.
If you re-instate a group share after revocation then all previously existing re-groupings and permissions are also re-instated. If a key has not yet been synced this will then have no impact on the shared-to account, unless the group share's roles have been changed.
If an account is purged following a group revocation, then all structures based on the share will be permanently erased.
The accounts to which group have been shared are summarized in the "Shared with" column under Groups. For a complete list access Groups / Edit / Shares.
In group lists and group selection boxes, a shared group is prefixed by the name of the sharing account in square backets: for example "[Sharing Account] Shared Group".
In lock lists all locks that are visible because of a group share are indicated in a blue italic font, and audit trail entries referencing shared locks are likewise colored.
The role you specify in the Groups / Edit / Shares / Group Role selection determines what the receiving account can do to the group itself.
Usually you will define only "View Entities" permission, so the receiving account can at least see the shared group. However, you may also permit the receiving account to modify the group, or modify membership of the group.
Note that group membership modification is a one-way street. If for example the shared group is a department, and you have allowed "Assign Locks to Departments" authorization, then an authorized user in the receiving account will be able to un-link a lock from the department. Subsequently the lock will be no longer accessible to that user.
The role you specify in the Groups / Edit / Shares / Member Role selection determines what the receiving account can do to locks in the shared group.
Usually you will allow "View Entities" so the receiving account can view the lock identities. In addition you will typically allow "Open locks" so keys can be authorized to open the shared locks. You may also allow other permissions, such as rights to edit lock fields.
A receiving account is permitted to re-group shared locks using groups defined within that account. As usual a shared lock may only be a member of one department in the receiving account, and this is still allowed if the lock is a member of a department in the sharing account. Shared locks may be made a member of any number of administrative groups. In these respects shared locks may be treated as if they are locks owned by the shared-to account.
If a group is un-shared, all such re-groupings will disappear. If the same group is re-shared, such groupings will be re-instated, unless the account has been purged in the meantime.
You may use a shared group directly in permissions rules defined for users, keys and other groups. For example in Users/Edit/Permissions/Add, shared groups are listed along with the other account groups for selection.
If a group used in such a permission is then un-shared, the permission becomes a 'shadow' permission. this means it remains visible, but is grayed out to indicate it is no longer active. You can edit or delete such permissions but you may not change the group.
Should the group be re-shared, all such 'shadow' permissions are re-instated.
All share and un-share operations are audited in both the sharing and shared-to account. The name of the user and the name of the roles specified in the share are visible on both accounts.
When you access a shared lock in a shared-to account it is audited like any other lock belonging to the account. The label of the shared lock is visible in the audit trail and the audit trail item is colored in a blue italic font.