Security
Overview
Avonni Dynamic Components is a 100% native, Salesforce-managed package. The components run inside your Salesforce org, on the same Lightning platform that already protects your records. They enforce your Field-Level Security, object permissions, and Sharing Rules; they transmit no data to any Avonni-hosted service; and the package passes the Salesforce AppExchange Security Review each year.
This page documents the architecture, the platform safeguards the package relies on, and the practices Avonni follows for vulnerability management, vendor access, and customer support. If your procurement or InfoSec team needs additional artifacts (security questionnaires, AppExchange review confirmation, a DPA, or an NDA), contact [email protected].
Security at a Glance
Hosting model
Native managed package. Runs inside your Salesforce org.
Data egress
None by default. Component data stays in Salesforce.
Vendor access to your data
None standing. Granted only via Salesforce Grant Login Access when you initiate it for a support session.
Authentication
Salesforce-managed. SSO, MFA, IP restrictions, and login policies all apply unchanged.
Field-Level Security
Enforced. Data access runs in AccessLevel.USER_MODE.
CRUD permissions
Enforced. Users without object permission cannot read or write through a component.
Sharing model
Respects org-wide defaults, role hierarchy, sharing rules, manual shares, and Apex managed sharing.
Encryption at rest
Inherited from Salesforce. Salesforce Shield Platform Encryption is supported transparently.
AppExchange Security Review
Passed. Re-reviewed annually.
Sub-processors for the package
None. Salesforce is the only platform provider.
Compliance posture
Inherits the compliance posture of your Salesforce org (SOC 1/2/3, ISO 27001/17/18, FedRAMP, HIPAA via Shield, GDPR, PCI-DSS, as applicable to your edition).
Security Architecture
Where the package runs
Avonni Dynamic Components is distributed as a Salesforce-managed package under the avonnidc namespace. When you install it, every artifact — Lightning Web Components, Apex classes, Custom Metadata Types, Custom Permissions, and static resources — is deployed inside your Salesforce org. There is no Avonni-hosted backend, no proxy server, no middleware. The runtime executes inside Salesforce's standard Lightning runtime, in the user's browser session, authenticated against your org.
Component definitions (layout, data sources, Interactions, visibility rules) are stored as records in the package's Custom Metadata Type (avonnidc__Dynamic_Component__mdt) inside your org. They are subject to the same backup, sandbox, and migration tooling as the rest of your metadata.
What leaves your org
By default, nothing. The components query Salesforce via Apex, the Lightning Data Service, and the User Interface API, render in the user's browser, and write back through standard DML — all within the Salesforce trust boundary.
The only exceptions are configurations that you set up explicitly:
Salesforce Connect / External Objects. If you point a component at an External Object, data flows according to the Salesforce Connect security model. Avonni does not change that path.
Outbound integrations. If you wire an Interaction to an Apex method that calls a Named Credential, the network call originates from Salesforce, governed by the Named Credential, Remote Site Settings, and the auth scheme you configured.
Embedded URLs. Iframe and "Open URL" interactions navigate the browser to URLs you specify; CSP Trusted Sites apply.
There is no telemetry channel back to Avonni. The package does not phone home, transmit error reports, or call a licensing server during runtime.
What Avonni stores
Avonni does not host, replicate, cache, or back up your Salesforce data. We have no production database storing customer record content. Information held by Avonni is limited to the standard business records associated with our customer relationship — account contact information, license entitlements, support correspondence, and billing data — held in our internal CRM and billing systems.
Salesforce Security Model
The package is built to defer to Salesforce's permission model at every layer. The policies your administrators have already configured apply to anything users do inside an Avonni component.
Field-Level Security and CRUD
All record reads and writes performed by the package run with AccessLevel.USER_MODE. This is Salesforce's modern enforcement mechanism: at the SOQL and DML layer, the platform validates the current user's FLS and CRUD permissions for every field and object touched, and rejects operations the user is not entitled to perform. Fields that a user cannot read are not returned to the browser. Fields a user cannot edit render read-only and DML against them fails at the platform layer before reaching the database.
Sharing Rules and Record Visibility
Record-level visibility follows your org configuration. The package respects org-wide defaults, role hierarchy, criteria, owner-based sharing rules, manual shares, team-based sharing, and Apex-managed criteria-based and owner-based sharing rules. A user who cannot see a record in a standard report or list view cannot see it through an Avonni component either.
A small number of internal Apex classes are declared without sharing because their only job is to read package-owned Custom Metadata (component definitions, picklist sources, configuration), which has no row-level access model. These classes never read your business records.
User Permissions and Builder Access
Builder access — the ability to open the Avonni Components App and design new components — is gated by Permission Sets shipped with the package. Standard end users do not need builder access to view or interact with components placed on a Lightning Page. This separates "people who build" from "people who use" through the same Permission Set model you already use for the rest of your org.
Encryption
Data at rest is encrypted by Salesforce. The package introduces no storage outside the Salesforce database, so all standard Salesforce encryption applies — including Shield Platform Encryption if your org has it enabled. Data in transit is protected by Salesforce's TLS termination at the platform edge.
AppExchange Security Review
Avonni Dynamic Components is a listed AppExchange package. To remain listed, the package must pass the Salesforce AppExchange Security Review and must be re-reviewed each year and after any material architectural change.
The review is conducted by Salesforce's Product Security team and covers, at a minimum:
Static and dynamic code analysis of all Apex, LWC, and Aura artifacts
CRUD and FLS enforcement across every entry point
SOQL/SOSL injection, DML injection, and shared-state vulnerabilities
Cross-site scripting (XSS) and cross-site request forgery (CSRF) defenses
Open redirect and insecure URL handling
Storage of secrets, credentials, and personally identifiable information
Use of Named Credentials, Remote Site Settings, and external endpoints
Lightning Locker Service and Lightning Web Security compliance
Click-jacking, framing, and Content Security Policy posture
The review is pass-or-fail. Packages that fail are removed from the AppExchange listing. The Avonni team produces evidence (test scripts, threat model, exception justifications) for each submission, and findings are tracked and remediated in line with Salesforce's required timelines.
If your procurement team requires the latest pass confirmation or the review summary, email [email protected].
Authentication and Access
How users authenticate
Users do not authenticate to Avonni. They authenticate to Salesforce, and Avonni components run inside that authenticated Salesforce session. Your existing SSO provider (Okta, Azure AD, Ping, Salesforce-as-IdP, and similar), multi-factor authentication policies, IP range restrictions, login flows, session timeouts, and device-trust rules all apply unchanged.
Avonni access to your Salesforce data
Avonni has no standing access to your org. We do not have credentials. We do not maintain an integration user. We cannot read your records.
The only way an Avonni support engineer can see your org is through the standard Salesforce Grant Login Access feature, which you initiate from your user record and which expires automatically after the duration you select. When access is granted:
The engineer logs in as your user, subject to your security policies
All actions are recorded in your Login History and Setup Audit Trail like any other session
Access ends at the expiration time you set, or when you revoke it manually
The Salesforce documentation for this feature is here: Grant Login Access to Salesforce Administrators.
Granting Login Access for support
We request Grant Login Access only when reproducing the problem in your environment is the fastest way to resolve a ticket. We will tell you exactly what we need to inspect, work read-only wherever possible, and ask you to revoke access once we are done. If your policy is to never grant external login access, tell [email protected] and we will work from screen-shares and exported configuration only.
Network and External Integrations
The base package makes no outbound network calls. There is no Avonni-hosted API, no licensing-server callback, no telemetry endpoint, and no CDN dependency for data delivery — static assets ship inside the package.
Outbound traffic occurs only when you configure it.
Apex callout invoked from an Interaction
Salesforce → your endpoint
Named Credential, Remote Site Setting, your auth scheme
External Object data source
Salesforce → external system
Salesforce Connect, External Data Source, OData / Cross-Org adapter
Iframe component
Browser → URL you specify
CSP Trusted Sites, your endpoint
Open URL interaction
Browser → URL you specify
Standard browser navigation
In every case, you authorize the destination through standard Salesforce setup, and you can audit it through standard Salesforce tooling (Setup Audit Trail, Login History, debug logs, Event Monitoring if licensed).
Data Storage and Residency
Because the package stores nothing outside your Salesforce org, data residency is tied to your Salesforce instance. If your org is hosted in the EU, your component data is in the EU. If your org is on Salesforce Hyperforce in a specific region, the same applies. Avonni does not replicate, mirror, or proxy your data to any other location.
Component definitions are stored as Custom Metadata Type records inside your org. They are subject to your existing backup, sandbox refresh, and metadata-migration practices. Uninstalling the managed package removes those records — export them first if you need to retain them. Your business records (the Salesforce data and the components query) are untouched by package uninstallation.
Vulnerability Management and Updates
Release and patch cycle
Avonni ships updates as new managed-package versions. Customers control when to upgrade through Setup → Installed Packages. Security-relevant fixes are flagged in the release notes and, when severity warrants it, communicated via, communicated by direct email to administrators of affected orgs.
Release notes for every version are published at docs.avonnicomponents.com. Each release indicates which entries are security-relevant.
Responsible disclosure
If you believe you have found a security vulnerability in Avonni Dynamic Components:
Do not post details publicly or in the Trailblazer Community group.
Email
[email protected]with a description, reproduction steps, and any proof-of-concept.We acknowledge within one business day and provide a triage timeline.
We coordinate disclosure with Salesforce Product Security when the issue requires platform-level coordination.
We do not currently run a paid bug bounty program. Researchers who report responsibly are credited in the affected version's release notes, on request.
Compliance and Trust
Because the package processes your data exclusively inside your Salesforce org, the certifications that apply to your Salesforce edition apply to anything your users do through Avonni components. Depending on your edition and add-ons, this can include:
SOC 1 / SOC 2 / SOC 3
ISO 27001, ISO 27017, ISO 27018
FedRAMP (Government Cloud)
HIPAA (with Salesforce Shield)
GDPR (Salesforce as a Data Processor)
PCI-DSS Level 1 (Salesforce platform)
The Salesforce Trust site at trust.salesforce.com and compliance.salesforce.com are the authoritative source for current certificates and reports.
Avonni is a Canadian company headquartered in Quebec. Avonni does not currently hold an independent SOC 2 attestation as a separate vendor — our package's runtime environment, Salesforce, is SOC 2-attested, and Avonni's own security posture is validated annually by the AppExchange Security Review. We share Salesforce's compliance documentation and our AppExchange review confirmation with procurement teams on request. For a Data Processing Addendum, mutual NDA, or a completed security questionnaire (SIG, CAIQ, or custom), email [email protected].
Shared Responsibility
Like every Salesforce extension, security is a shared model.
Building the package to pass AppExchange Security Review
Configuring components, queries, and Interactions in line with your security policies
Enforcing FLS, CRUD, and sharing in the package's Apex and LWC code
Maintaining correct FLS, CRUD, and sharing settings on the objects components touch
Publishing release notes with security-relevant changes flagged
Reviewing release notes and upgrading the package on a cadence you decide
Responding to responsible-disclosure reports within one business day
Reporting suspected issues to [email protected] rather than public channels
Limiting our access to your data to customer-initiated Grant Login Access
Granting, scoping, and revoking login access; reviewing the Setup Audit Trail
Keeping production credentials and customer business data confidential
Salesforce user management, SSO, MFA, IP restrictions, and session policies
Last updated
Was this helpful?