Skip to main content

Permissions

Permissions define the actions users can perform in Incident IQ and the sections they can access.

Key Concepts

  • Unified User Roles
    In iiQ, a user’s Role (e.g., Agent, Requestor) is a global attribute.

    • Cross-Module Impact: If a user is an "Agent" in the Technology Module, they are also an "Agent" in Facilities.

    • The "Login" Rule: Access to specific modules (Ticketing, Facilities, HRSD, etc.) is NOT automatic. Users must be granted the Login Permission within each module to see it in their product navigation drop-down.

  • Additive Policy
    Permissions in iiQ are strictly additive.

    • Policies cannot overwrite permissions granted by another policy.

  • Inclusion & Exclusion Filters
    When defining who a policy "Applies To," you can use filtering:

    • Required Inclusion: You cannot have an exclusion without an inclusion. If you add an exclusion filter on a single line, you are essentially assigning this policy to EVERY user EXCEPT those you have specifically excluded.

    • The "All But" Logic: To target everyone except a specific group, you must include "All Users" and then add the specific user or role to the Exclusion field. The following image shows the applies to ALL users except those with the role of Agent.

  • Visibility & Navigation Controls

    • View Left Nav: This specific permission must be enabled for a user to see the left-hand navigation menu for a section (e.g., "View User Left Nav" is required to see and use the User Explorer).

      ​​

    • List Assets: To allow users (like teachers) to submit tickets for assets they do not personally own, the List Assets permission must be enabled.

  • Additional Call Outs

    • Permission policies are managed within their respective products.

    • When viewing a User Profile within a specific module, the system only displays the policies relevant to that module.

    • Mobile App experience and app search will remain in parity with the web version experience.

    • All permissions (view, etc) will be reflected in the “Search” capabilities throughout iiQ. Limitations on what can be viewed by location are honored in Global Search, User Explorer, Asset Explorer areas, and more.


Permissions List

  • Navigation: Admin > Permissions (located in the left navigation menu).

  • Baseline: Use "out of the box" permission policies as templates for different roles.

  • Search: Filter policies by Name across both Active and Archive tabs.

Column Name

Definition

Policy Name

Name of the policy.

Description

Optional description explaining the policy's purpose.

Applies To

The Condition(s) that you have applied to policy (e.g., Role, User, Team, etc).

Status

  • Active: This refers to a permission policy that is live and currently applied to the assigned users. It means the policy is currently in effect and actively governs the permissions of the assigned users.

  • Inactive: This refers to a permission policy that is not currently active for the assigned users. It indicates that the policy is not currently in effect and is not actively governing the permissions of the assigned users.

    • Use this option when you need to initiate policy creation but prefer to keep it inactive until further adjustments are made.

  • Archive: Archived policies are moved to the Archived Tab and are not currently applied to assigned users.

Policies Tab Actions

  • Copy: Duplicates Name, Description, "Applies To" logic, and all granted permissions.

  • Archive: Moves a policy to the Archive tab.

Archive Tab Actions

  • Unarchive: Restores a policy to the All Policies tab (you will be prompted to set status to Active or Inactive).

  • Delete: Permanently removes a policy.

    • Warning: This action is irreversible.

Bulk Actions

  • Policies Tab: You can perform bulk Status Changes or Archive actions via the toolbar.

  • Archive Tab: Users can perform bulk Unarchive or Delete actions via the toolbar.


Create a New Policy From Scratch

  • Action: Select +New Policy from the top-right corner of the Permissions Page.

First, you will set the status of the new permission policy.

  • Active: Policy is live, and currently governs assigned users.

  • Inactive: Policy is saved but not applied. Use this for drafting or mid-adjustment phases.

Next, enter a Name (required) and a Description (optional). You will use the ‘Applies To’ section to add conditional filters that a user must meet to be assigned to the policy, such as User, Role, Location, OU Path, and Is External Requestor.

You can include an exclusion filter when applying conditions to permission policies.

  • Required Inclusion: You cannot have an exclusion without an inclusion. If you add an exclusion filter on a single line, you are essentially assigning this policy to EVERY user EXCEPT those you have specifically excluded.

  • The "All But" Logic: To target everyone except a specific group, you must include "All Users" and then add the specific user or role to the Exclusion field.

When adding condition filters, you have:

  • In Addition (AND): Strict requirement. Users must meet all conditions.

    • Example: Filters applied are a specific Team, AND another filter is Role = Admin. User John Smith is assigned to that team, but his role is NOT Admin. He will not be assigned this policy because his role does not equal Admin.

  • Or When (OR): Broad requirement. Users must meet at least one condition.

    • Example: You want to apply a policy to the "Agent Role" OR WHEN the user is part of the "Student Agent Team."

      • Let’s say John Smith's role is “Student,” but he is part of the “Student Agent Team.” This policy would be applied to this user because he is part of the student agent team.

Next, you can grant permission options to the policy. Permissions are grouped: Section (Product Area) > Permission Group (Functional Set). Additional sections may be visible based on the modules, apps, and integrations your district has purchased or installed.

Example:

Section = Parts
Permission Groups =

  • Parts

  • Parts Access

  • Parts Inventory

You can select a single permission option or check the box next to a Permission Group to enable all its underlying options. Hover over the information icon for granular definitions of specific permissions.

Certain permission sections allow for adding Condition Filters and Condition Groups:

  • Condition Filters: Add a location condition filter.

  • Condition Groups: Add the same set of permissions groups.

  • Bulk Actions: Use Bulk Actions > Set Filters to apply location filters to multiple permissions simultaneously.

    • Note: Bulk setting filters replace existing filters; they do not append them.

You can use the Summary View (Read-Only) toggle to filter out unselected options and view only the permissions enabled within the policy.


User Profile Permissions List

Open the User Profile page and scroll to the bottom to locate the permissions section.

When viewing a user profile in a specific Incident IQ module (e.g., Assets, Tickets, Facilities), the system only displays the permission policies assigned to the user for that module. Permission policies from other modules are suppressed to prevent cross-module confusion.


Export Permission Policies

The export feature generates a comprehensive snapshot of all defined permission policies within a specific module.

  • Trigger Action: Click the Export option (located in the top-right corner).

  • Output Format: Structured CSV file that includes the columns Name, Description, Applies To, and Total Users (number of users per policy).

Did this answer your question?