# Groups and permissions
Users have a permission model that is based on their group membership. Groups are accessible in Orderwave by navigating to Settings > Groups.
Orderwave comes with the following groups predefined by default:
| Group | Description |
|---|---|
| Users | This is the basic group that is for non-administrator persons in Orderwave. By default, they have permission to do everything that is not a part of the Admin section in Orderwave. |
| Admins | These are the administrators of Orderwave, a group that you will need to be a member of in order to do most of the administration in this guide. |
| Bots | This is the default group for your API users. API users are users that won't be logging into the Orderwave UI, but instead, will be calling out to Orderwave APIs. |
| External | This group is for users that are not a part of your organization, and are likely not directly interacting with the Orderwave UI, but are using a custom implementation, like an order status portal. |
# Permission strategies
It is encouraged that you create groups that match your needed permission model. As an example, you may want to have "Users" that have less permissions than "Managers". To accomplish this, you would remove permissions from the "Users" group that are not needed the for standard daily activities for general customer service, and apply only those permissions to a new "Managers" group. Then, your managers could be members of both "Users" and "Managers", having a combination of the permissions from both. If a user is a member of multiple groups, they have access to all of the permissions from the group memberships combined.
# Creating a new group
To create a new group, navigate to and click the ➕ button to create the group, and fill in the following field:
| Field | Description |
|---|---|
| Name | The group name. This is a unique identifier for the group. |
# Setting permissions
After your group is created, navigate to the new group, and click the Set Permissions button at the top of the group detail screen. This will pop-up a window with a list of all of the permissions that are available. Each bucket is listed in this window. Permissions are categorized by bucket. Each bucket has at least the following standard permissions:
| Permission | Description |
|---|---|
| Add Tags | Lets the user tag the item with a predefined tag. |
| Add To Queue | Lets the user add the item to a predefined queue. |
| Aggregate Queues | Lets the user see aggregate counts of queues for this bucket on dashboard screens. |
| Archive | Allows the user to delete the item. |
| Create | Lets the user create new items. |
| Detail | Lets the user see the detail data of the item. |
| Get Copy Json | Allows the user to create a similar item as the item they are viewing on the screen, by pulling a copied version. |
| Get Links | Lets the user retrieve/see the links on items. |
| Link | Lets the user link the item to another item, or an external URL. |
| List | Lets the user see a list of items on their respective main "list" screens (or APIs for the case of Bots). |
| Lock | Allows the user to change the lock status on an item. |
| Remove From Queue | Lets the user click the ✖ button on a queued item to remove it from that queue. |
| Remove Gate | Lets the user remove unique control gates on items. |
| Remove Link | Allows the user to remove a link from an item by clicking the trash icon button. |
| Remove Tags | Lets the user click the ✖ on a tag to remove it from an item. |
| Rule Button | Lets users execute various buttons that you have created with Rules. |
| Set Tags | Allows the user to create new tags that can be used on the item. |
| Update | Allows the user to open the "edit" ✏ windows and change the item. |
TIP
This is not a complete list of permission options that are available for each bucket, as buckets have specialized permissions for their specific actions. For example, the oms/orders bucket has permission options for "Cancel", "Cancel Items", "Clear Order To FulFill", etc.
# Using rules to customize permissions
Group-based permissions are often enough for a tightly controlled permission model for most organizations. However, sometimes it is advantageous to create a rule that makes the resulting action respond with a permission error, so that the specific user cannot continue with the action. These types of rules have the ability to inspect object data for specific conditions, as well as inspect the current username of groups to define the conditions in which a permission error should occur.
Example 💡
A common example is that you do not want users from a certain group to remove a queue from an order. Let's use this example to detail how this rule would be configured.
For this example:
- The "Users" group will keep their Orders [Oms] "Remove From Queue" permission, so that they can continue to remove most queues from orders.
- A fictional queue with the queue-code "POTENTIAL-FRAUD" will be configured with a rule to not let members of "Users" to remove it from orders.
Follow these steps:
- Create a new rule on the oms/orders bucket.
- Edit rule parameters and choose "dequeue" as the trigger.
- Make sure the Match field is set to "All".
- Choose "user.groups[any].name" as the Field or JSON path to match.
- Choose "is" as the Operator.
- Enter "Users" s the Value to compare
- Click the blue ➕ with the tooltip Add a field/JSON path
- Choose "dequeued.queueCode" as the Field or JSON path to match.
- Choose "is" as the Operator.
- Choose "POTENTIAL-FRAUD" as the Queue Code.
- For the Choose an action field, select "No permission".
- Under User groups, choose "Users" as the groups that cannot do this action.
The preceding steps ensure that for only the "POTENTIAL-FRAUD" queue code, when a user from the group "Users" attempts to dequeue it, Orderwave will respond with an action that returns a no-permission error. Users from the "Users" group can continue to remove queues from orders with different queue codes without problems.