When an AI QA scoring engine receives a truncated or partially masked ticket, it doesn't fail loudly. It simply scores what it can see, which means incomplete data produces systematically skewed quality scores without any warning. The fix is almost always a permissions problem, not a product problem. In Salesforce, that means auditing Salesforce field level security settings to confirm your integration profile can read every relevant field [1]. In Zendesk, it means checking that your API token has the right role and that conditional ticket fields are visible to the integration. This guide gives you a field-by-field checklist for both platforms so your scoring engine gets complete conversation data, every time.
TL;DR
- Incomplete field permissions are the most common reason AI QA engines produce unreliable scores.
- In Salesforce, field-level security is controlled at the profile and permission-set level; the integration user must have "Read" access on every field it needs to evaluate [1][2].
- In Zendesk, role restrictions and conditional ticket fields are the two most frequent causes of missing data in API payloads [4].
- Treat your integration user as a read-only auditor role with access to all conversation-relevant fields, not a standard agent account.
- A complete data feed is the prerequisite for 100% conversation coverage; fix permissions before tuning scoring logic.
Why does missing field access break AI QA scoring?
AI QA scoring depends entirely on reading the full conversation context before applying your QA scorecard. If a field is hidden from the integration user, the scoring engine receives a null value or a blank string, which it treats as absence of information rather than a permissions error. The result is that scores appear valid but are built on incomplete evidence.
Common fields that get silently dropped include:
- Custom ticket fields (e.g., escalation reason, product category, SLA tier)
- Internal notes or private comments
- Agent identity and team assignment fields
- Linked case or order data pulled from a CRM object
- Sentiment or satisfaction tags appended by other customer service automation tools
Each of these provides context that changes how a QA scorecard should be applied. A response scored without knowing the ticket's SLA tier, for example, may pass a generic politeness check while actually violating a specific escalation policy.
How do you configure Salesforce field level security for an integration user?
Salesforce controls what a user can read at the field level through a combination of profiles and permission sets [1][2]. The integration service account your QA platform uses must be granted "Read" access, at minimum, on every field that carries conversation-relevant data.
Step-by-step: granting field read access via the Object Manager
- In Salesforce Setup, open Object Manager using the Quick Find box [1][3].
- Select the object containing the field (e.g.,
Casefor support tickets). - Click Fields & Relationships, then open the specific field [1].
- Click Set Field-Level Security [3].
- Locate the profile assigned to your integration user (e.g., "API Integration Profile").
- Check the Visible checkbox. Leave Read-Only checked to prevent accidental writes [2][3].
- Save and repeat for each field your QA engine needs to read.
What fields to prioritise on the Case object
| Field | Why it matters for QA scoring |
|---|---|
| Case Comments (public and private) | Contains the full agent-customer dialogue |
| Case Reason / Type | Determines which SOP the AI should retrieve |
| Owner (Agent ID) | Required for per-agent scoring and coaching views |
| Escalated (boolean) | Triggers escalation-handling criteria in the scorecard |
| Custom SLA / Product fields | Contextualises policy requirements |
A practical tip: create a dedicated permission set named something like "QA Integration Read Access" and assign it to your service account rather than modifying the base profile. This makes it easier to audit and maintain as your QA scorecard evolves [2].
How do you configure Zendesk permissions for a QA integration?
Building on the Salesforce setup above, Zendesk uses a different but equally important access model. Rather than field-level security on objects, Zendesk gates data access through agent roles, API token scopes, and ticket field visibility rules [4].
Role configuration for the integration account
- Create a dedicated agent account for the QA integration. Do not reuse a human agent's credentials.
- Assign the account a custom role (available on Suite Professional and above) with read access to all tickets, including tickets not assigned to that agent [4].
- Enable access to internal notes. In many Zendesk configurations, internal notes are restricted to specific groups by default, which means the integration account misses all private agent commentary.
Conditional and custom ticket fields
Zendesk allows admins to create ticket fields that only appear under certain conditions (e.g., a "Refund Amount" field that appears only when ticket type is "Billing"). These fields are still present in the API payload, but only if the integration user's role has access to the parent form. Verify this by:
- Going to Admin Center > Objects and Rules > Ticket Forms.
- Checking that your QA integration account's group can see every ticket form in use.
- Using the Zendesk API to pull a sample ticket and comparing the returned fields against your full field list [4].
How do you verify the integration is receiving complete data before going live?
Permissions changes should always be validated before your scoring engine processes production volume. A gap you don't catch here becomes a systematic scoring error across every ticket.
Validation checklist
- Pull a raw API response. Use your integration credentials to fetch a known ticket via the API and inspect the full JSON payload. Any field returning
nullthat should have a value signals a permissions gap. - Test across ticket types. A field present on a billing ticket may be absent on a general enquiry ticket. Validate across at least three ticket categories.
- Check internal notes separately. Private comments often require explicit role grants and will not surface in a standard ticket fetch without them.
- Confirm agent identity fields. Your QA platform needs to attribute every score to a specific agent. Verify that agent ID, name, and team fields are populated in every response.
- Re-validate after any Salesforce profile or Zendesk role change. Permission changes made for other operational reasons can inadvertently remove access for your integration account.
Frequently Asked Questions
What is the difference between Salesforce field-level security and object-level permissions?
Object-level permissions control whether a user can see a record type at all (e.g., the Case object). Field-level security controls which individual fields within that object are readable or editable. An integration user may have access to Case records but still be blocked from reading specific fields like custom SLA tiers or internal escalation flags [1][2].
Can I use a standard Zendesk agent account for my QA integration instead of a dedicated one?
You can, but it is not recommended. A standard agent account typically has group-scoped ticket access, meaning it can only see tickets assigned to its group. A QA scoring engine needs to read all tickets regardless of assignment. Using a dedicated account with a custom administrator-level read role avoids this constraint and makes permission auditing much cleaner [4].
Will fixing field permissions affect my production Salesforce or Zendesk environment?
Read-only field access grants on a dedicated integration profile do not affect how human agents interact with the system. The change is scoped to that profile or permission set only, and granting "Read" without "Edit" carries no write-side risk [2].
What happens if my AI QA engine scores a ticket with missing fields?
The engine scores based on the data it receives. Missing fields are treated as absent information, not as errors. This means the score may appear valid while actually being based on an incomplete picture of the conversation. Systematic field gaps produce systematic scoring bias that is difficult to detect after the fact.
Do I need to reconfigure permissions if I add a new custom field to Zendesk or Salesforce?
Yes. New fields in Salesforce default to no visibility for existing profiles unless explicitly granted [2]. In Zendesk, new ticket fields added to a form may not be accessible to all agent roles automatically. Build a permissions review into your process whenever new fields are added.
Does this apply to AI agent (chatbot) conversations as well as human agent tickets?
Yes. If you are running AI chatbots alongside human agents and want to score both consistently, the same data completeness requirements apply. The QA scoring engine needs the same field access regardless of whether the conversation was handled by a human or a bot.
How does a Zendesk and Salesforce integration relate to QA scoring?
Many enterprise teams use both platforms, with Salesforce holding customer and account data and Zendesk handling the support queue [4]. A QA scoring engine that can pull from both gets richer context per ticket, for example linking a support case to a customer's account tier or contract terms. That context directly affects which policies the scoring engine should apply.
About Revelir AI
Revelir AI builds RevelirQA, an AI customer service QA software that scores 100% of customer service conversations against your own SOPs and QA scorecard. Unlike manual QA sampling, which typically covers only 1-5% of tickets, RevelirQA evaluates every conversation, every agent, with a full audit trail showing the prompt, documents retrieved, and reasoning behind each score.
RevelirQA is in production at Xendit and Tiket.com, processing thousands of tickets per week across English, Indonesian, Thai, and Tagalog. The platform evaluates both human agents and AI chatbots within a single consistent scoring framework, giving CX and support operations leaders a unified view of quality across their entire customer service operation.
Revelir integrates with any helpdesk via API, including Zendesk and Salesforce, and deploys as SaaS or a dedicated tenant for compliance-critical environments.
Ready to eliminate scoring gaps and get 100% conversation coverage?
Learn how RevelirQA connects to your helpdesk and starts scoring from day one.
References
- Salesforce Help (help.salesforce.com)
- Field Level Security in Permissions - Trailhead - Salesforce (trailhead.salesforce.com)
- How To Add Field-Level Security to Type Fields in Salesforce Lightning : Customer Support Portal (support.outreach.io)
- Zendesk Salesforce Integration | Complete Guide 2025 (www.minusculetechnologies.com)