wiki/knowledge/salesforce/quarra-permission-analysis.md Layer 2 article 451 words Updated: 2026-03-19
↓ MD ↓ PDF
salesforce quorra permissions field-level-security lincoln-durham security

Quarra Salesforce Permission Analysis & Recommendations

Overview

During a working session on 2026-03-19, an AI-powered permission audit was conducted on the Quorra Salesforce org. The analysis produced two documents delivered to Lincoln Durham for review prior to the next client meeting:

  1. Quorra Stone Salesforce Permissions — a full summary of the current permission setup, including profiles, permission sets, and validation rules
  2. Quorra Stone QR Permissions Recommendate — a set of AI-generated recommendations for improving the org's security posture

Both documents were saved to the shared drive under Projects > Salesforce.


Current State Summary

The permission audit pulled all permission-related data from the org via the Salesforce API, including:

The resulting document ran to approximately 11 pages.


Key Findings & Recommendations

Lincoln Durham — Admin Profile Risk

Finding: Lincoln Durham, Director of Sales, holds full System Administrator access to the Quorra org.

Risk: A System Administrator can modify metadata, delete any record, change automation, install packages, and alter field mappings org-wide. For a non-technical sales leader, this represents a significant accidental-change risk — a single errant click in Setup could break flows, validation rules, or field mappings across the entire org.

Recommendation: Downgrade Lincoln Durham from the System Administrator profile to a more appropriate profile (e.g., a Core Executive profile) that provides the data access he needs without exposing destructive Setup capabilities.

Note for client communication: Frame these as AI-generated recommendations, not team opinions. Lincoln should feel free to accept, modify, or reject any suggestion. The goal is to start a conversation about access governance, not to prescribe a specific outcome.


Inactive Users

During the audit, a test/legacy user (Jessica) was identified as still active in the org. This user should be deactivated.


Strategy for Next Meeting

The permission documents are intended as a conversation starter, not a final implementation plan. The recommended approach for the next client meeting:

  1. Walk Lincoln Durham through both documents together
  2. Ask him to indicate what he wants to keep, change, or add for each user/role
  3. Record the meeting with [2] to capture all decisions
  4. Feed the Fathom transcript to [3] to automate implementation of the agreed-upon permission set changes via the Salesforce API

This approach avoids manual note-taking errors and allows the AI to handle the bulk of the implementation work directly from the client's stated requirements.