Permissions and Security

HARi gives you fine-grained control over data access. Decide exactly who can view, edit, create, and delete records, down to the individual field level.

Security profiles

Every user is assigned a security profile. Profiles define what the user can do across all entities.

Typical profiles:

Profile	Description
Admin	Full access to everything, including settings and schema
Sales Manager	Full access to CRM data, can see all records, manage teams
Sales Rep	Access to own records and team records, cannot delete
Viewer	Read-only access to selected entities

You can create as many profiles as your organization needs.

Capabilities

Each profile has capabilities per entity:

• Create — can create new records
• Read — can view records
• Update — can edit records
• Delete — can delete records
• Export — can export data to CSV
• Import — can import data from CSV
• Bulk update — can update multiple records at once

Capabilities follow a logical hierarchy: if you can update, you can also read. HARi enforces this automatically.

Record ownership

Every record has an owner (the user who created it or was assigned to it). Ownership controls visibility:

• Own records only: user sees only records they own
• Team records: user sees records owned by anyone in their team
• All records: user sees everything (typically for managers)

This is configured per profile, per entity.

Field-level security

Beyond record-level access, you can control which fields a profile can see or edit:

• Visible: the field appears on forms and lists
• Read-only: the field is visible but cannot be edited
• Hidden: the field is completely invisible to this profile

Example: sales reps can see deal amounts but only managers can edit the discount percentage.

Deactivating a user

When a teammate leaves the workspace, you deactivate their account from Settings → Users. To prevent records from becoming invisible (records owned by an inactive user are filtered out of most views), HARi forces an explicit decision about ownership before the deactivation goes through.

When you click Deactivate, a dialog opens showing what the user owns:

• The number of records they own per entity (contacts, opportunities, tasks, etc.)
• Their personal team (if they have one)
• Any team where they’re the only active member

You then choose one of two paths:

• Transfer records to another teammate. Pick the new owner from the active-user list. Every active record they currently own is reassigned in one transaction. The audit log records the transfer (one entry per entity) so you can see exactly what moved. Tick Notify the new owner to send a single summary message (“X reassigned 47 records to you”) to their notification bell — off by default to avoid the per-record notification noise.
• Skip the reassignment. Leave the records on the deactivated account with a short note explaining why (for example: “Returning in 3 months — keep records as-is”). This is recorded in the audit log so the next admin understands the choice.

If the user has a personal team, you can also opt to delete it on deactivation — useful when the personal team has no other purpose. For shared teams where the leaver is the only active member, you can pick a replacement owner team per row.

Reactivating a user

Reactivating an account is one click — the green/grey status pill on the user’s profile flips back. What happens then is deliberately conservative:

• Login is re-enabled. The user can sign in again with their existing credentials (or use the password-reset flow if they’ve forgotten).
• Records do not auto-revert. Whatever was transferred to teammates during deactivation stays with those teammates. If the returning user genuinely needs their old records back, an admin can reassign them manually — explicitly, on a case-by-case basis, with the audit log capturing the move.
• Team memberships stay as they were. Deactivation never removes someone from a team, so reactivation has nothing to restore.
• Personal team is not auto-recreated. Personal teams are an implementation detail used for permission scoping, not business data; if the returning user actually needs one again, an admin creates it through the standard team-create flow.

The conservative default is intentional. A returning teammate doesn’t surprise the people who took over their pipeline — they keep their work, and the returning user can negotiate any handover with them directly.

Audit log

Every change in HARi is recorded in the audit log:

• Who made the change
• When it happened
• What was changed (old value and new value)
• Which record was affected

Access the audit log from the History tab on any record.

The audit log is partitioned by month for performance. Administrators can configure retention policies to automatically archive or purge old entries.

Best practices

1. Start with the principle of least privilege — give users only the access they need
2. Use team-based visibility for sales organizations — reps see their pipeline, managers see everything
3. Protect sensitive fields (revenue, margin, discount) with field-level security
4. Review the audit log regularly to spot unusual activity
5. Test new profiles by logging in as a test user with that profile before rolling it out