Security Fundamentals

At SystemsAnalytix, we know that managing incidents often involves handling sensitive data. IncidentAnalytix is built on the robust Microsoft Power Platform security model, which allows you to control exactly who sees what.

This guide explains how security works, from broad access roles down to hiding specific sensitive fields.

1. Security Roles: The “Keys to the Castle”

Think of a Security Role as a job description or a digital ID badge. Every user who logs into IncidentAnalytix must be assigned at least one security role. This role dictates what they can do within the system.

The 8 Actions

When we assign a role, we are granting permission to perform specific actions on data (like an Incident record):

Create: Can the user make a new record?
Read: Can the user view existing records?
Write: Can the user edit or update data?
Delete: Can the user permanently remove a record?
Append: Can the user attach this record to another record? (e.g., attaching a Note to an Incident).
Append To: Can the user attach other records to this one?
Assign: Can the user change the owner of a record (e.g., assigning an Incident to a colleague)?
Share: Can the user give someone else access to a record they normally wouldn’t see?

Access Levels: “My Stuff” vs. “Everyone’s Stuff”

Just because you can “Read” incidents doesn’t mean you can read all of them. Security roles define the Scope of your access:

User Level (Basic): You can only see records that you own or created.
Business Unit Level (Local): You can see records owned by anyone in your specific department or team.
Organization Level (Global): You can see all records in the entire system.

Example: A Incident Reporter might only see Incidents they reported (User Level), while a Risk Manager sees all Incidents in their department (Business Unit Level) and an Admin sees all Incidents across the Organization.

2. Security for Forms and Views

Security isn’t just about data; it’s also about the user interface. We can tailor the experience so users only see what is relevant to them.

Security on Forms

An “Incident” might have 50 different fields, but a regular employee only needs to see 10 of them to report an issue. A Compliance Officer, however, needs to see all 50.

How it works: We can create different Forms (screens) for the same record. We then assign specific Security Roles to each form.
The Result: When a regular user opens an Incident, they see a simple form. When a manager opens the exact same Incident, they see a detailed form with extra tabs for investigation.

Security on Views

A “View” is the list of records you see (e.g., “Active Incidents”).

How it works: We can create specific views that filter data automatically and assign them to roles.
The Result: A manager might see a view called “High Priority Risks,” while a standard user simply sees “My Open Requests.”

3. Getting Granular: Column Level Security

Sometimes, you need to let a user see a record (like an Incident), but hide a specific piece of sensitive information on it (like a Social Security Number or a confidential settlement amount).

This is handled by Column Level Security.

The Lock: We configure specific sensitive columns to be “Secured.” By default, if a column is secured, users will see it as blank or locked with a key icon.
The Key (Column Security Profile): To let someone see the data in that locked field, we add them to a Column Security Profile. This profile grants Read, Update, or Create access specifically for that field.

4. Advanced Privacy: Data Masking

For highly sensitive data (PII), we use advanced features to obfuscate information so it is visible but unreadable to unauthorized users. This involves three components:

Attribute Masking Rule & Secured Masking Rule

These rules define how the data is hidden. Instead of hiding the field entirely (which creates a blank space), masking replaces the characters with symbols to maintain privacy while confirming data exists.

Attribute Masking Rule: This is the logic we apply to a field. For example, a rule might state: “For email addresses, show the first letter but replace everything else with asterisks.”
Secured Masking Rule: This usually refers to the implementation of regex (regular expression) patterns that identify and mask the data format (like credit card numbers or tax IDs).

Visual Example:

Unmasked: [email protected]

Masked: j*******@example.com

Column Security Profile (for Masking)

Just like with standard column security, the Column Security Profile is how we handle exceptions.

Most Users: Will see the masked version (j*******@example.com).
Authorized Users: Users added to the specific Column Security Profile will “bypass” the mask and see the plain text ([email protected]).

Summary Table

Feature	What it Controls	Best Used For
Security Role	Actions (Create, Read, Write)	Defining job functions (e.g., Manager vs. User).
Form/View Security	Layout and Lists	Simplifying the interface; showing relevant data only.
Column Security	Specific Fields	Hiding highly sensitive data (e.g., Salary) entirely.
Data Masking	Field Content Obfuscation	PII compliance (e.g., showing `**-**-1234` for IDs).

5. Real-World Use Cases

To help you decide how to configure IncidentAnalytix for your team, here are three common scenarios illustrating how these security layers work together.

Scenario A: The “Incident Reporter” vs. The “Risk Manager”

The Goal: You want all employees to be able to report accidents, but they shouldn’t see accidents reported by other people. However, the Safety Manager needs to see everything to analyze trends.
Configuration:
- Role 1 (Incident Reporter): We assign them a role with Create permission (so they can report) and User Level Read permission.
  - Result: They can log in and report a slip-and-fall. They see a list of incidents, but it only contains the ones they submitted.
- Role 2 (Risk Manager): We assign them a role with Organization Level Read/Write permission.
  - Result: They see the slip-and-fall reported by the Standard Employee, plus every other incident in the system, regardless of who reported it.

Scenario B: Protecting Sensitive Investigations (Form Security)

The Goal: When an incident is flagged as a “Harassment Complaint,” it requires a specialized investigation. Standard managers should not see the sensitive notes taken by HR during the investigation.
Configuration:
- Forms: We create two main forms:
  1. “Intake Form” (Visible to everyone): Shows basic details like Date, Location, and Description.
  2. “HR Investigation Form” (Visible only to HR Role): Shows the Intake details plus extra tabs for “Witness Statements,” “Disciplinary Action,” and “Legal Notes.”
- The Outcome: If a facility manager opens the record, they only see the facts of the incident on the Intake Form. If an HR Director opens the same record, IncidentAnalytix automatically loads the “HR Investigation Form,” allowing them to document sensitive details securely.

Scenario C: Financial Privacy & Identity Protection (Column Security & Masking)

The Goal: The Finance team needs to record the “Insurance Settlement Amount” for liability claims. The Safety team needs to read the claim to prevent future accidents, but they should not know how much money was paid out. Additionally, user Social Security Numbers (SSN) must be captured but hidden from casual view.
Configuration:
- Column Security: We enable security on the “Insurance Settlement Amount” column.
  - We create a profile called “Finance Team” and give them Read and Update access.
  - Result: The Safety Manager sees the incident, but the “Insurance Settlement Amount” field appears with a generic lock icon or is blank. The Finance Manager sees the dollar figure (e.g., $15,000).
- Data Masking: We apply an Attribute Masking Rule to the “SSN” column.
  - Result: When a user looks at the record, they see ***-**-6789. This confirms the data exists without revealing the full identity. Only users with the specific “Unmasking” privilege can click to reveal the full number.

IncidentAnalytix

Getting Started

Security