NFR Definition for Salesforce
This skill activates when a team needs to define and document non-functional requirements (NFRs) for a Salesforce implementation before design begins or before go-live sign-off. It produces a structured NFR register with measurable acceptance criteria grounded in Salesforce platform realities: governor limits, the shared responsibility availability model, compliance control requirements, and usability benchmarks.
Before Starting
Gather this context before working on anything in this domain:
- Confirm the Salesforce org edition and feature set — NFRs for a Government Cloud org with Shield differ substantially from a standard Enterprise edition org.
- Establish the business criticality tier: what is the cost of one hour of downtime, one day of data unavailability, or a compliance breach? This sets the stakes for each NFR category.
- Identify the 3-year scale horizon — user count, record counts per major object, daily transaction volume, API call volume. Governor limits are hard ceilings; you need headroom calculations now, not at go-live.
- Confirm which regulations apply. GDPR, HIPAA, and PCI-DSS each impose specific technical controls that must appear as NFRs, not as vague security goals.
- The most common wrong assumption: "Salesforce handles availability — we don't need to define it." This confuses infrastructure uptime (Salesforce's responsibility) with data recovery, custom code reliability, and integration availability (customer's responsibility).
Core Concepts
NFR Categories for Salesforce
The five categories that must always appear in a Salesforce NFR register, mapped to Well-Architected pillars:
Performance (Performance Efficiency pillar) — Page load times, report execution times, batch job completion windows, API response times. Must be expressed as Service Level Indicators (SLIs): "95th-percentile Lightning page load under 3 seconds measured in a Full sandbox." Vague targets ("fast") cannot be tested.
Scalability (Performance Efficiency + Reliability pillars) — Salesforce governor limits are hard, non-negotiable platform ceilings, not soft guidelines. Every scalability NFR must be expressed relative to these limits. Key limits: SOQL rows per transaction (50,000), DML statements per transaction (150), CPU time per transaction (10,000 ms Apex), heap size (6 MB sync / 12 MB async), synchronous callout timeout (120 s), daily API request allocation (varies by edition/user count). Architect for 50% headroom against any limit that correlates with data growth.
Availability (Reliability pillar) — Salesforce Trust publishes a 99.9% infrastructure uptime SLA. This covers the platform — it does NOT cover: custom Apex code reliability, integration availability, org-to-org data sync, or data recovery time after a misconfigured bulk delete. The NFR register must distinguish infrastructure availability (Salesforce's SLA) from application availability (team's responsibility) and define RPO/RTO for backup scenarios.
Security and Compliance (Trusted pillar) — Regulations impose specific technical controls. GDPR requires data maps, right-to-erasure workflows, and audit logs. HIPAA requires encryption at rest (Shield Platform Encryption or Field Encryption), audit trails (Field History Tracking or Event Monitoring), and BAA with Salesforce. PCI-DSS scopes may require tokenisation or out-of-scope data routing. Each applicable regulation should generate a named NFR with a testable acceptance criterion.
Usability (Easy pillar) — Page load time (overlap with performance), field count per page layout (recommend ≤ 30 visible fields per layout for cognitive load), mobile readiness (percentage of workflows completable on Salesforce Mobile), accessibility compliance (WCAG 2.1 AA for public or government-facing pages).
Well-Architected Framing
Salesforce organises its Well-Architected Framework across three top-level pillars: Trusted (security, compliance, reliability), Easy (usability, process efficiency), and Adaptable (scalability, resilience, composability). Every NFR category maps to at least one pillar. Using this framing ensures NFRs survive architecture reviews and are traceable to platform guidance.
Measurability Requirement
An NFR is only useful if it can be tested. Every NFR must include:
- A metric (what to measure)
- A threshold (acceptable vs. unacceptable value)
- A measurement method (where, when, and how to measure)
- An environment qualifier (sandbox tier, load profile)
Example of an untestable NFR: "The system must be responsive." Example of a testable NFR: "95% of Lightning record page loads complete in under 3 seconds, measured via browser-side performance tracing in a Full sandbox with 10 concurrent users simulated."
Common Patterns
Pattern 1: Governor Limit Translation
When to use: When business stakeholders provide scale targets like "we expect 500,000 cases per year" or "50 integrations running hourly."
How it works:
- Collect business scale numbers (records/day, concurrent users, API calls/day, batch window).
- Map each to the relevant governor limit category.
- Calculate expected utilisation as a percentage of the limit.
- Flag any dimension that exceeds 50% utilisation at the 3-year horizon as an architectural constraint requiring a design decision (e.g. async processing, chunking, Platform Events).
Why not the alternative: Treating governor limits as implementation details discovered during development leads to emergency re-architecture at go-live. They are first-class architectural constraints and must appear in the NFR register.
Pattern 2: Compliance Control Decomposition
When to use: When the project operates under a named regulation (GDPR, HIPAA, PCI-DSS, SOC 2).
How it works:
- Identify each applicable regulation.
- For each regulation, list the specific technical controls it requires.
- For each control, create a named NFR with a testable acceptance criterion tied to a Salesforce feature (Shield Encryption, Event Monitoring, Field Audit Trail, Connected App policies).
- Assign an owner (Salesforce admin, security team, data officer).
Why not the alternative: Listing "must be GDPR compliant" as a single NFR is untestable and unassignable. It will be interpreted differently by every reviewer and will fail a compliance audit.
Pattern 3: Availability Responsibility Mapping
When to use: Always — for every implementation. The shared responsibility model is never optional to document.
How it works:
- List every availability concern: infrastructure uptime, custom code reliability, batch job completion, integration uptime, data recovery.
- For each concern, assign responsibility to either Salesforce (infrastructure SLA) or the customer team.
- For customer-owned concerns, define RPO (recovery point objective) and RTO (recovery time objective).
- Document how each concern will be monitored (Salesforce Health Check, custom monitoring flows, integration heartbeats).
Decision Guidance
| Situation |
Recommended Approach |
Reason |
| Performance target is vague ("fast enough") |
Define SLI with percentile, threshold, and measurement method |
Untestable NFRs cannot gate go-live or be used in capacity planning |
| Scale target exceeds 50% of a governor limit at 3-year horizon |
Raise as architectural constraint requiring design decision now |
Governor limits cannot be increased; redesign is cheaper before build |
| Regulation named but controls not enumerated |
Decompose into per-control NFRs with Salesforce feature mapping |
Audit-ready compliance requires control-level traceability |
| Business says "we need 99.99% uptime" |
Separate infrastructure SLA (Salesforce's 99.9%) from application reliability (team's responsibility) |
Salesforce's SLA covers infrastructure only; custom code is team-owned |
| Project lacks usability NFRs |
Add layout field count limits, mobile completion targets, WCAG level |
Usability regressions are caught late and expensive to fix post-launch |
Recommended Workflow
Step-by-step instructions for an AI agent or practitioner working on this task:
- Collect project scope — org edition, feature set, regulatory context, integration landscape, and 3-year user and data volume projections.
- For each of the five NFR categories (performance, scalability, availability, security/compliance, usability), draft at least two measurable NFRs using the SLI format: metric, threshold, measurement method, environment qualifier.
- Translate business scale targets into governor limit utilisation percentages. Flag any dimension exceeding 50% at the 3-year horizon as an architectural constraint.
- Map each applicable regulation to the specific Salesforce features that satisfy its controls. Create one NFR per control, not one NFR per regulation.
- Document the availability shared responsibility split: which availability concerns are covered by Salesforce's infrastructure SLA, and which are customer-owned (with RPO/RTO defined).
- Review the NFR register against the Well-Architected pillars — Trusted, Easy, Adaptable — to confirm all three are addressed.
- Validate each NFR has a test method and an assigned owner. Remove or escalate any NFR that cannot be verified in a test environment.
Review Checklist
Run through these before marking work in this area complete:
Salesforce-Specific Gotchas
Non-obvious platform behaviors that cause real production problems:
Governor limits are per-transaction, not per-request — SOQL row limits (50,000), DML statements (150), and CPU time (10,000 ms) reset at transaction boundaries. An NFR that says "the system must handle 1 million records per day" is valid at the batch level but a single synchronous transaction cannot process more than 50,000 rows. NFRs must specify the unit of measurement and the processing mode (sync vs. async).
Salesforce's 99.9% uptime SLA does not cover org-level outages from bad deployments — A Metadata API deployment that breaks a critical trigger is not covered by the Trust infrastructure SLA. Customer-owned application availability must be explicitly scoped in the NFR register with a separate RTO/RPO.
Scale testing requires Full sandbox — Developer Pro is not a valid proxy — Developer Pro sandboxes have a 200 MB storage limit and do not replicate production data volume or record distribution. Performance NFRs validated only in Developer Pro sandboxes will produce invalid results. Full sandboxes are the minimum for load-representative performance testing.
Output Artifacts
| Artifact |
Description |
| NFR Register |
Structured document with one row per NFR: category, metric, threshold, measurement method, environment, owner, status |
| Governor Limit Translation Table |
Business scale targets mapped to Salesforce limit categories with utilisation percentages at launch and 3-year horizon |
| Availability Responsibility Matrix |
Per-concern split between Salesforce infrastructure SLA and customer-owned availability, with RPO/RTO for customer-owned items |
| Compliance Control Checklist |
Per-regulation breakdown of required controls mapped to Salesforce features, with testable acceptance criteria |
Related Skills
- ha-dr-architecture — use after NFR definition to design the technical solution for availability and recovery NFRs
- limits-and-scalability-planning — use to investigate specific governor limit headroom once scalability NFRs are defined
- security-architecture-review — use to validate that security and compliance NFRs are met by the org configuration
- well-architected-review — use to assess the full implementation against all three Well-Architected pillars
1---2name: nfr-definition-for-salesforce3description: Defining measurable non-functional requirements for Salesforce implementations: performance SLIs, scalability targets, availability SLAs, security and compliance requirements, usability benchmarks. Use when starting architecture design or preparing for go-live sign-off. NOT for technical implementation of those requirements. NOT for HA/DR planning (use ha-dr-architecture). NOT for individual governor limit investigation (use limits-and-scalability-planning). NOT for security controls implementation (use security-architecture-review).4---5
6# NFR Definition for Salesforce
7
8This skill activates when a team needs to define and document non-functional requirements (NFRs) for a Salesforce implementation before design begins or before go-live sign-off. It produces a structured NFR register with measurable acceptance criteria grounded in Salesforce platform realities: governor limits, the shared responsibility availability model, compliance control requirements, and usability benchmarks.
9
10---
11
12## Before Starting
13
14Gather this context before working on anything in this domain:
15
16- Confirm the Salesforce org edition and feature set — NFRs for a Government Cloud org with Shield differ substantially from a standard Enterprise edition org.
17- Establish the business criticality tier: what is the cost of one hour of downtime, one day of data unavailability, or a compliance breach? This sets the stakes for each NFR category.
18- Identify the 3-year scale horizon — user count, record counts per major object, daily transaction volume, API call volume. Governor limits are hard ceilings; you need headroom calculations now, not at go-live.
19- Confirm which regulations apply. GDPR, HIPAA, and PCI-DSS each impose specific technical controls that must appear as NFRs, not as vague security goals.
20- The most common wrong assumption: "Salesforce handles availability — we don't need to define it." This confuses infrastructure uptime (Salesforce's responsibility) with data recovery, custom code reliability, and integration availability (customer's responsibility).
21
22---
23
24## Core Concepts
25
26### NFR Categories for Salesforce
27
28The five categories that must always appear in a Salesforce NFR register, mapped to Well-Architected pillars:
29
301. **Performance** (Performance Efficiency pillar) — Page load times, report execution times, batch job completion windows, API response times. Must be expressed as Service Level Indicators (SLIs): "95th-percentile Lightning page load under 3 seconds measured in a Full sandbox." Vague targets ("fast") cannot be tested.
31
322. **Scalability** (Performance Efficiency + Reliability pillars) — Salesforce governor limits are hard, non-negotiable platform ceilings, not soft guidelines. Every scalability NFR must be expressed relative to these limits. Key limits: SOQL rows per transaction (50,000), DML statements per transaction (150), CPU time per transaction (10,000 ms Apex), heap size (6 MB sync / 12 MB async), synchronous callout timeout (120 s), daily API request allocation (varies by edition/user count). Architect for 50% headroom against any limit that correlates with data growth.
33
343. **Availability** (Reliability pillar) — Salesforce Trust publishes a 99.9% infrastructure uptime SLA. This covers the platform — it does NOT cover: custom Apex code reliability, integration availability, org-to-org data sync, or data recovery time after a misconfigured bulk delete. The NFR register must distinguish infrastructure availability (Salesforce's SLA) from application availability (team's responsibility) and define RPO/RTO for backup scenarios.
35
364. **Security and Compliance** (Trusted pillar) — Regulations impose specific technical controls. GDPR requires data maps, right-to-erasure workflows, and audit logs. HIPAA requires encryption at rest (Shield Platform Encryption or Field Encryption), audit trails (Field History Tracking or Event Monitoring), and BAA with Salesforce. PCI-DSS scopes may require tokenisation or out-of-scope data routing. Each applicable regulation should generate a named NFR with a testable acceptance criterion.
37
385. **Usability** (Easy pillar) — Page load time (overlap with performance), field count per page layout (recommend ≤ 30 visible fields per layout for cognitive load), mobile readiness (percentage of workflows completable on Salesforce Mobile), accessibility compliance (WCAG 2.1 AA for public or government-facing pages).
39
40### Well-Architected Framing
41
42Salesforce organises its Well-Architected Framework across three top-level pillars: Trusted (security, compliance, reliability), Easy (usability, process efficiency), and Adaptable (scalability, resilience, composability). Every NFR category maps to at least one pillar. Using this framing ensures NFRs survive architecture reviews and are traceable to platform guidance.
43
44### Measurability Requirement
45
46An NFR is only useful if it can be tested. Every NFR must include:
47- A metric (what to measure)
48- A threshold (acceptable vs. unacceptable value)
49- A measurement method (where, when, and how to measure)
50- An environment qualifier (sandbox tier, load profile)
51
52Example of an untestable NFR: "The system must be responsive." Example of a testable NFR: "95% of Lightning record page loads complete in under 3 seconds, measured via browser-side performance tracing in a Full sandbox with 10 concurrent users simulated."
53
54---
55
56## Common Patterns
57
58### Pattern 1: Governor Limit Translation
59
60**When to use:** When business stakeholders provide scale targets like "we expect 500,000 cases per year" or "50 integrations running hourly."
61
62**How it works:**
631. Collect business scale numbers (records/day, concurrent users, API calls/day, batch window).
642. Map each to the relevant governor limit category.
653. Calculate expected utilisation as a percentage of the limit.
664. Flag any dimension that exceeds 50% utilisation at the 3-year horizon as an architectural constraint requiring a design decision (e.g. async processing, chunking, Platform Events).
67
68**Why not the alternative:** Treating governor limits as implementation details discovered during development leads to emergency re-architecture at go-live. They are first-class architectural constraints and must appear in the NFR register.
69
70### Pattern 2: Compliance Control Decomposition
71
72**When to use:** When the project operates under a named regulation (GDPR, HIPAA, PCI-DSS, SOC 2).
73
74**How it works:**
751. Identify each applicable regulation.
762. For each regulation, list the specific technical controls it requires.
773. For each control, create a named NFR with a testable acceptance criterion tied to a Salesforce feature (Shield Encryption, Event Monitoring, Field Audit Trail, Connected App policies).
784. Assign an owner (Salesforce admin, security team, data officer).
79
80**Why not the alternative:** Listing "must be GDPR compliant" as a single NFR is untestable and unassignable. It will be interpreted differently by every reviewer and will fail a compliance audit.
81
82### Pattern 3: Availability Responsibility Mapping
83
84**When to use:** Always — for every implementation. The shared responsibility model is never optional to document.
85
86**How it works:**
871. List every availability concern: infrastructure uptime, custom code reliability, batch job completion, integration uptime, data recovery.
882. For each concern, assign responsibility to either Salesforce (infrastructure SLA) or the customer team.
893. For customer-owned concerns, define RPO (recovery point objective) and RTO (recovery time objective).
904. Document how each concern will be monitored (Salesforce Health Check, custom monitoring flows, integration heartbeats).
91
92---
93
94## Decision Guidance
95
96| Situation | Recommended Approach | Reason |
97|---|---|---|
98| Performance target is vague ("fast enough") | Define SLI with percentile, threshold, and measurement method | Untestable NFRs cannot gate go-live or be used in capacity planning |
99| Scale target exceeds 50% of a governor limit at 3-year horizon | Raise as architectural constraint requiring design decision now | Governor limits cannot be increased; redesign is cheaper before build |
100| Regulation named but controls not enumerated | Decompose into per-control NFRs with Salesforce feature mapping | Audit-ready compliance requires control-level traceability |
101| Business says "we need 99.99% uptime" | Separate infrastructure SLA (Salesforce's 99.9%) from application reliability (team's responsibility) | Salesforce's SLA covers infrastructure only; custom code is team-owned |
102| Project lacks usability NFRs | Add layout field count limits, mobile completion targets, WCAG level | Usability regressions are caught late and expensive to fix post-launch |
103
104---
105
106## Recommended Workflow
107
108Step-by-step instructions for an AI agent or practitioner working on this task:
109
1101. Collect project scope — org edition, feature set, regulatory context, integration landscape, and 3-year user and data volume projections.
1112. For each of the five NFR categories (performance, scalability, availability, security/compliance, usability), draft at least two measurable NFRs using the SLI format: metric, threshold, measurement method, environment qualifier.
1123. Translate business scale targets into governor limit utilisation percentages. Flag any dimension exceeding 50% at the 3-year horizon as an architectural constraint.
1134. Map each applicable regulation to the specific Salesforce features that satisfy its controls. Create one NFR per control, not one NFR per regulation.
1145. Document the availability shared responsibility split: which availability concerns are covered by Salesforce's infrastructure SLA, and which are customer-owned (with RPO/RTO defined).
1156. Review the NFR register against the Well-Architected pillars — Trusted, Easy, Adaptable — to confirm all three are addressed.
1167. Validate each NFR has a test method and an assigned owner. Remove or escalate any NFR that cannot be verified in a test environment.
117
118---
119
120## Review Checklist
121
122Run through these before marking work in this area complete:
123
124- [ ] Every NFR has a metric, threshold, measurement method, and environment qualifier
125- [ ] All applicable governor limits are represented as scalability NFRs with utilisation calculations
126- [ ] The availability NFR register separates Salesforce infrastructure SLA from customer-owned availability
127- [ ] Each applicable regulation has been decomposed into per-control NFRs, not a single "must be compliant" statement
128- [ ] Usability NFRs include page load time, layout field count limits, and mobile readiness targets
129- [ ] Every NFR has an assigned owner
130- [ ] No NFR uses vague adjectives (fast, secure, reliable) without a measurable threshold
131
132---
133
134## Salesforce-Specific Gotchas
135
136Non-obvious platform behaviors that cause real production problems:
137
1381. **Governor limits are per-transaction, not per-request** — SOQL row limits (50,000), DML statements (150), and CPU time (10,000 ms) reset at transaction boundaries. An NFR that says "the system must handle 1 million records per day" is valid at the batch level but a single synchronous transaction cannot process more than 50,000 rows. NFRs must specify the unit of measurement and the processing mode (sync vs. async).
139
1402. **Salesforce's 99.9% uptime SLA does not cover org-level outages from bad deployments** — A Metadata API deployment that breaks a critical trigger is not covered by the Trust infrastructure SLA. Customer-owned application availability must be explicitly scoped in the NFR register with a separate RTO/RPO.
141
1423. **Scale testing requires Full sandbox — Developer Pro is not a valid proxy** — Developer Pro sandboxes have a 200 MB storage limit and do not replicate production data volume or record distribution. Performance NFRs validated only in Developer Pro sandboxes will produce invalid results. Full sandboxes are the minimum for load-representative performance testing.
143
144---
145
146## Output Artifacts
147
148| Artifact | Description |
149|---|---|
150| NFR Register | Structured document with one row per NFR: category, metric, threshold, measurement method, environment, owner, status |
151| Governor Limit Translation Table | Business scale targets mapped to Salesforce limit categories with utilisation percentages at launch and 3-year horizon |
152| Availability Responsibility Matrix | Per-concern split between Salesforce infrastructure SLA and customer-owned availability, with RPO/RTO for customer-owned items |
153| Compliance Control Checklist | Per-regulation breakdown of required controls mapped to Salesforce features, with testable acceptance criteria |
154
155---
156
157## Related Skills
158
159- ha-dr-architecture — use after NFR definition to design the technical solution for availability and recovery NFRs
160- limits-and-scalability-planning — use to investigate specific governor limit headroom once scalability NFRs are defined
161- security-architecture-review — use to validate that security and compliance NFRs are met by the org configuration
162- well-architected-review — use to assess the full implementation against all three Well-Architected pillars
aibot88