Customizing Permission & Approval Groups in Canix

The Basics

Structuring Groups Around Your Team

Designing Approval Workflows

Practical Setup Approach

The Basics

Q: What's the difference between "Action Permissions" and "Approval Permissions" in Canix?

They control two different things, and most teams need both configured together:

• Action Permissions decide what a user can see and do — Edit, View, or No Access — across every section of Canix (Plants, Harvests, Inventory, Sales, Manufacturing, Task Management, Reporting, Admin, Integrations, Labor Costs, etc.).
• Approval Permissions decide whether a submission needs a second set of eyes before it's final — who can submit-and-require-approval, and who can review-and-approve. This layers on top of Action Permissions; a user still needs Edit access to an action before "Requires Approval" applies to them.

Think of Action Permissions as the door, and Approval Permissions as the checkpoint some people have to pass through after walking in.

Q: Where do I go to set these up?

Analyze & Support > Admin & Settings > User Permission Groups. From there you can create a new group, edit an existing one, or expand any section's row to get more granular than the top-level Edit/View/No Access toggle.

Q: What are the three permission access levels?

• Edit – can see the page/data and has the ability to transact on the corresponding functions
• View – can see the page/data but can't submit or change anything. Helpful for roles where another team’s data informs their decision making. 
• No Access – the section disappears from that user's navigation entirely. Streamlines the user experience and keeps data private where needed.

Structuring Groups Around Your Team

Q: Should permission groups mirror my org chart, or my workflow?

Workflow, not job titles. Canix's permission model is organized by function area (Plants, Harvests, Inventory, Sales, etc.), so the cleanest approach is to build a permission group per functional role - the set of actions a person actually performs day to day - and then assign employees to the group that matches their job. In some cases. two people with different titles may end up in the same group or vice versa.

Q: How are permission groups typically broken out?

Requirements can differ depending on your team structure or size. The table below provides an overview of settings for common roles. 

Keep in mind that each permission section has multiple sub-settings that allows you to control individual functions more granularly. 

Typically, companies with very defined teams or roles will have more permission groups to control for the different sub-setting options.

Q: What if someone's role spans two of these role-based buckets?

Two main options:

1. Build a distinct group for that hybrid role
2. Keep the base functional group and add the extra permissions needed, but control the additional tasks using the Approvals tab

Most operations end up with more permission groups than job titles once leads and supervisors are accounted for — that's normal. See the Approvals section below for more information.

Q: Should every task-management user see all tasks, or just their own?

That's controlled directly: Tasks (Own) lets a user view/complete only tasks assigned to them; Tasks (All) lets them create and manage tasks regardless of assignee. Line-level staff typically get Tasks (Own) only; supervisors who build schedules get Tasks (All) plus Templates/Workflows access.

Designing Approval Workflows

Q: How do approval groups actually work?

For each functional area (Plant Batches, Plants, Harvests, Packages, Transfers, Manufacturing, Items, Locations, Strains), a permission group can be a submitter, an approver, both, or neither - set independently per action.

• Requires Approval - related submissions go to a pending queue instead of posting immediately
• Can Approve – this group can review and approve/deny pending submissions in that area
• Both - related submissions will require approval, but they can self approve
• Neither - this groups transactions will be submitted without further review

Q: Where do I turn approvals on?

Admin > User Permission Groups > select the group > Approval Permissions tab. From there, expand each section (Plant Batches, Plants, Harvests, Packages, etc.) to set Can Approve / Requires Approval down to individual actions rather than the whole category.

Q: Who typically needs "Requires Approval" turned on?

New hires, seasonal or temporary staff, and any role where risk is high if a mistake goes live immediately - for example, destroying plants, or creating packages from a harvest, or adjusting packages. 

Some considerations for high risk submissions include:

• Transactions being sent to your state’s seed-to-sale system
• Transactions with direct compliance implications, regardless of whether they’re submitted to a state seed-to-sale system (for example, editing a finished good label template)
• Transactions that are not correctable, or require contacting Canix / your regulators for intervention (differs by state)
• Transactions that may significantly affect the team's ability to make data-based decisions if incorrect (for example, creating facility data outside convention that will affect reporting or creating inventory with incorrect quantities)

Q: Who should be a "Can Approve" user?

Supervisors, compliance leads, or facility managers who are already trained on the compliance implications of the action being approved (e.g., a cultivation manager approving plant destructions, a facility manager approving package location changes). Keep this list short — Approval Permissions work best when a small number of trusted reviewers are covering a queue, not when everyone can approve everyone.

Q: Can I require approval on some actions within a section but not others?

Yes -  expand the section (e.g., Packages) and set Requires Approval for individual actions as needed. This lets you require approval only on the actions that carry compliance or inventory risk, while letting routine actions post immediately.

Practical Setup Approach

Q: What's a good sequence for actually building this out?

1. List your functional roles (not job titles) — e.g., Cultivator, Trimmer, Packaging Lead, Sales Rep, Compliance Manager, Accounting.
2. Map each role to the sections it touches and whether that touch should be Edit, View, or No Access.
   • Reference the Permission Groups help article for more detailed information on what each setting controls
3. Build one permission group per role in Admin > User Permission Groups, using the expand/collapse rows to fine-tune beyond the section-level default.
4. Layer in Approval Permissions only where a role's actions carry meaningful risk — start narrow, expand later if it's not enough friction (or loosen if it's creating bottlenecks).
5. Assign users to groups in Admin > User Management.
6. Test with one user per group before rolling out company-wide — have them try both an allowed and a restricted action to confirm the group behaves as expected.

Q: Any common pitfalls to watch for?

• Chained dependencies: several actions quietly depend on access elsewhere — e.g., unpacking clones to plantings needs Package view/edit access; splitting packages in a sales order needs Split & Combine Packages access; creating a sales order from a LeafLink order needs edit access to Sales Orders (Own). Test the full workflow a role performs, not just the primary action.
• Over-restricting Reporting: Reporting permissions are separate from operational permissions - a user can have no Edit access to Sales but still need Reporting > Sales to do their job.
• Forgetting Labor Costs nuance: "Labor Hours Only" vs. "Labor Costs and Labor Hours" is a common mix-up — the first hides wage/COGS data while still showing hours, which is often what you want for line supervisors who schedule labor but shouldn't see pay rates. The Permission Groups help article has a video specifically covering the labor costs settings
• Too many approvers: if everyone can approve, the approval step stops being a meaningful check. Keep the "Can Approve" list to people who are actually accountable for that compliance area.