---
title: Quarra Permission Set Analysis & Recommendations
type: article
created: '2026-04-05'
updated: '2026-04-05'
source_docs:
- raw/2026-03-19-quarra-sf-work-131352190.md
tags:
- salesforce
- quarra
- permissions
- security
- ai-assisted
layer: 2
client_source: null
industry_context: null
transferable: true
---

# Quarra Permission Set Analysis & Recommendations

## Overview

As part of ongoing Salesforce work for [[wiki/clients/quarra/_index|Quarra]], a full permission structure analysis was conducted using the Salesforce API and an AI assistant. Two documents were produced and shared with the client:

1. **QR Quaristone Salesforce Permissions** — a summary of the current permission structure, including profiles, permission sets, and validation rules
2. **QR Quaristone Salesforce Permissions Recommendations** — AI-generated suggestions for changes to improve security and role hygiene

Both documents are stored in the shared drive under `Projects > Salesforce`.

## Process

Mark used the Salesforce API to pull all permission-related data from the Quarra org (profiles, permission sets, validation rules). The raw output was fed to an AI assistant, which:

- Summarized the current state into a readable document
- Generated a second document with prioritized recommendations

The recommendation document was framed for the client as AI-generated suggestions — not Asymmetric mandates — to keep the conversation collaborative and avoid putting Lincoln on the defensive.

## Key Findings

### Lincoln Durham — System Administrator Profile

The most significant finding was that Lincoln Durham (Director of Sales) holds a **System Administrator** profile.

**Risk:** Admin access allows Lincoln to:
- Modify metadata
- Delete any record
- Change automation (flows, validation rules)
- Install packages
- Make org-wide configuration changes

One accidental click in Setup can break flows, validation rules, or field mappings across the entire org.

**Recommendation:** Downgrade Lincoln's profile from `System Administrator` to `Core Executive`.

### Jessica (Inactive User)

A user named Jessica (Mark's daughter, added during initial setup) was identified as still active in the org. She should be deactivated.

### Validation Rules

The permissions export also surfaced existing validation rules, which don't strictly relate to permissions but are useful context for understanding org-wide restrictions.

## Delivery Strategy

When presenting these documents to Lincoln:

- Frame both documents as **AI-generated analysis**, not Asymmetric's personal opinion
- Invite Lincoln to review and decide which recommendations to act on
- Use the permissions call as a working session: have Lincoln talk through what he wants each user to be able to do, capture it via Fathom, then implement changes via API

> "You don't want him to think that we think he's going to break everything." — Mark

## Action Items

- [ ] Email Lincoln both documents (permissions summary + AI recommendations), noting they are AI-generated and requesting his review (@Karly Oykhman)
- [ ] Deactivate Jessica's user account in the Quarra Salesforce org (@Karly Oykhman)
- [ ] On next call with Lincoln: walk through recommendations together and capture decisions for API implementation (@Karly Oykhman / @Mark Hope)

## Related

- [[wiki/clients/quarra/_index|Quarra Client Overview]]
- [[wiki/knowledge/salesforce/task-details-field-api-workaround|Task Details Field — API Workaround]]
- [[wiki/knowledge/salesforce/opportunity-primary-contact-lookup|Opportunity Primary Contact Lookup Field]]
- [[wiki/knowledge/salesforce/using-api-for-permission-changes|Using the Salesforce API for Permission Changes]]