# 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 `security@avonni.app`. *** ## Security at a Glance
TopicPosition
Hosting modelNative managed package. Runs inside your Salesforce org.
Data egressNone by default. Component data stays in Salesforce.
Vendor access to your dataNone standing. Granted only via Salesforce Grant Login Access when you initiate it for a support session.
AuthenticationSalesforce-managed. SSO, MFA, IP restrictions, and login policies all apply unchanged.
Field-Level SecurityEnforced. Data access runs in AccessLevel.USER_MODE.
CRUD permissionsEnforced. Users without object permission cannot read or write through a component.
Sharing modelRespects org-wide defaults, role hierarchy, sharing rules, manual shares, and Apex managed sharing.
Encryption at restInherited from Salesforce. Salesforce Shield Platform Encryption is supported transparently.
AppExchange Security ReviewPassed. Re-reviewed annually.
Sub-processors for the packageNone. Salesforce is the only platform provider.
Compliance postureInherits 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 `security@avonni.app`. *** ## 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](https://help.salesforce.com/articleView?id=000323031\&type=1\&mode=1). ### 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 `support@avonni.app` 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. | Configuration | Where the traffic originates | What controls 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](https://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 `security@avonni.app` 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](https://trust.salesforce.com) and [compliance.salesforce.com](https://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 `security@avonni.app`. *** ## Shared Responsibility Like every Salesforce extension, security is a shared model. | Avonni is responsible for | You are responsible for | | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | 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 `security@avonni.app` 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 | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.avonnicomponents.com/dynamic-components/resources/security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.