Snapshot 64436
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Trust, Security & Data Processing Your data never leaves your own systems. Every ADL Connect app runs inside a platform you already trust — the Salesforce AppExchange package in your Salesforce org, the Atlassian Marketplace app in your Jira site, the Visual Studio Marketplace extension in your Azure DevOps organisation. We operate no servers, no middleware and no database of our own — so there is no ADL-hosted copy of your data, and no sub-processors touching it. This page is our standing answer to security, privacy and procurement reviews. Sub-processor list Salesforce security review Applies to every ADL Connect app on AppExchange, Atlassian Marketplace & Visual Studio Marketplace · Last reviewed September 2026 Data BoundaryADL Connect · runs in-tenant NATIVE Your Own Tenants Customer recordsCases, opportunities, custom objects Never exported ADL Connect appsIn your Salesforce org, Jira site & ADO org Managed pkg OAuth 2.0 credentialsEncrypted, held by each platform In-org only No ADL servers · No middleware · No data lake · No analytics pixel Egress destinationOnly your own Jira / Azure DevOps / ServiceNow / Zendesk / Xurrent Question 1 Data processing documentation We do not store, process or transfer customer data on our own systems. All processing happens inside your own Salesforce, Jira and Azure DevOps tenants, under the agreements you already hold with those vendors. Question 2 Sub-processor list Zero sub-processors for customer data — across all three marketplaces. Because nothing leaves your own tenants, there is no third party in the processing chain for us to disclose. Question 3 AppExchange security review Our AppExchange package has passed Salesforce's mandatory security review. Our Atlassian and Visual Studio Marketplace apps are listed under each vendor's own review and vetting process. Section 01 Architecture & deployment model 100% Native At a glance Managed package installed in your org Runs on Salesforce Platform (Apex/LWC) ADL infrastructure in the data path: none Auth OAuth 2.0 / Named Credentials Uninstall removes the app entirely Reviewer shortcut: the set of hosts the Salesforce package can reach is fully visible to you in Setup → Remote Site Settings / Named Credentials, and the Jira and Azure DevOps apps declare their permissions and connection scopes at install time. If our domain is not in those lists — and it is not — we cannot receive your data. ADL Connect ships as three marketplace apps — a Salesforce AppExchange managed package, an Atlassian Marketplace app for Jira, and a Visual Studio Marketplace extension for Azure DevOps. Each one installs into your own tenant of that platform and runs there. There is no ADL-hosted tier behind any of them. 1What "native" means here Many integration products are in fact external iPaaS or middleware services: your records are pulled out to a vendor-run cloud, transformed there, and pushed on. That vendor then becomes a processor of your data and must publish a sub-processor list, a DPA and hosting details. ADL Connect is not built that way. Whichever app you install, the connector logic executes inside the platform tenant that hosts it — as Apex under the Salesforce governor model, or as app code inside your Jira site or Azure DevOps organisation. The only outbound traffic is the call your tenant makes directly to your own other system. As our Visual Studio Marketplace listing puts it, the extension is backend-less: there is no ADL server sitting between the two. No ADL application servers — we run no compute that handles your records, for any of the three apps. No ADL database — we maintain no store, cache, queue or data lake containing customer data. No relay or proxy — traffic goes tenant → your endpoint, never tenant → ADL → endpoint. No telemetry on record content — we do not ship record payloads off-platform for analytics. 2The only network egress From the Salesforce side, sync traffic leaves your org through Salesforce's own outbound HTTP layer (Apex callouts), governed by Remote Site Settings / Named Credentials that your administrator explicitly authorises. From the Jira and Azure DevOps side, the app calls your Salesforce org directly over an OAuth 2.0 connection your administrator approves. In every direction the two endpoints are systems you already own. 3Applies to the whole suite The same architecture applies to every ADL Connect app on every marketplace, so a single architectural review covers all of them. Where each ADL Connect app runs App Marketplace Installs into ADL-hosted component Talks directly to ADL Connect managed package Salesforce AppExchange Your Salesforce org None Your Jira, ADO, ServiceNow, Zendesk or Xurrent Salesforce Connector for Jira Atlassian Marketplace Your Jira site None Your Salesforce org Salesforce Connector for Azure DevOps Visual Studio Marketplace Your Azure DevOps org None Your Salesforce org Scroll horizontally to see all columns Within the Salesforce package, the same model covers every connector in the suite: Connectors inside the AppExchange package Connector Runs in ADL-hosted component Egress target ADL Connect for Jira Your Salesforce org None Your Jira site ADL Connect for Azure DevOps Your Salesforce org None Your ADO organisation ADL Connect for ServiceNow Your Salesforce org None Your ServiceNow instance ADL Connect for Zendesk Your Salesforce org None Your Zendesk subdomain ADL Connect for Xurrent Your Salesforce org None Your Xurrent account Section 02 Data processing policy No ADL processing Controller / processor You — controller of CRM data Salesforce / Atlassian / Microsoft — your processors, under your own DPAs ADL Solution — not a processor of your records Target system — your own tenancy, your own terms Salesforce Trust & Compliance Documentation Salesforce Infrastructure & Sub-processors Being precise about the last two rows. Like every marketplace partner, we receive licence-management data (org or site ID, app version, licence seat count, admin contact) from Salesforce's License Management App and from the Atlassian and Microsoft partner portals — this is platform metadata, not your records. And if your team emails us a screenshot or a debug log during a support case, that content reaches our business systems. We flag both so this page survives a real vendor-security questionnaire rather than overstating a clean "we touch nothing". ADL Solution does not store, process or transfer any customer data on its own systems. Each of our applications is designed to work entirely within the platform that hosts it, so all data interactions are confined to your own Salesforce, Jira and Azure DevOps tenants and to the destination system you configure. 1What the connector actually touches ADL Connect reads the Salesforce records your administrator maps (for example Cases or a custom object) and writes the corresponding work item into your target system, then keeps the two in step. Every one of those operations is executed by Apex running in your org, using the permissions of the Salesforce user or integration user you designate. 2Role under GDPR For the data flowing through the connector you remain the data controller, and Salesforce, Atlassian and Microsoft are your processors under the agreements you already hold with each of them. Because ADL Connect introduces no ADL-side processing of that data, ADL Solution does not act as a processor of your records at all. Where we do handle limited business-contact and support data, we act as an independent controller for that narrow set. 3The governing agreement Data processing for our applications is covered by the DPA of whichever platform hosts the app — Salesforce's for the AppExchange package, Atlassian's for the Jira app, Microsoft's for the Azure DevOps extension. Since we neither store nor handle data outside those platforms, the security measures, breach-notification terms, audit rights and transfer mechanisms in your existing agreements are the controls that apply to the data in scope. Processing register Data category Processed by ADL? Where it lives Retained by ADL CRM records (Cases, Opportunities, custom objects) No Your Salesforce org None Jira issues / ADO work items No Your Jira site / ADO organisation None Synced field values & comments No Your org + your target system None Attachments / files No Your org + your target system None Integration credentials / OAuth tokens No Encrypted in the platform that stores them None Sync logs & error records No Custom objects in your org / app storage in your tenant None Package / app licence & install metadata Marketplace-provided Salesforce LMA, Atlassian & Microsoft partner portals Org or site ID, licence status, admin contact Support correspondence you send us Yes, if you send it Our business email / ticketing Per support policy Scroll horizontally to see all columns Section 03 Data storage & processing location Your region Where data sits Primary the data centre of each platform you use Secondary your own target-system tenancy ADL-controlled locations none Worth stating plainly for your reviewer: an integration by definition moves data between two systems. ADL Connect adds no third location — but the transfer between your two tenants' regions is a real data flow that your own transfer assessment should cover. We are happy to document the exact field-level scope of that flow for your records. Because each application operates solely within the platform that hosts it, any data that interacts with it remains in that platform's data centres — Salesforce's, Atlassian's or Microsoft's. No external systems, servers or middleware are involved, so residency is determined entirely by the tenants you already run — not by anything ADL controls. 1Residency follows your org If your Salesforce org is provisioned in the EU, your Salesforce data stays in the EU. The same logic applies to your Jira site's Atlassian data residency setting and to the region of your Azure DevOps organisation. ADL Connect introduces no additional region, no cross-border replication and no secondary copy, because there is no ADL storage layer that could hold one. Data at rest — in your Salesforce org, Jira site or Azure DevOps organisation, in the region each vendor provisioned for you. Data in transit — TLS-encrypted calls from your tenant directly to your configured endpoint. Secondary copies — none held by ADL Solution. Onward transfer by ADL — none, as there is no ADL-side processing to transfer from. 2Your target system's residency Both halves of any integration are tenancies you own, each governed by your agreement with that vendor — Salesforce, Atlassian, Microsoft, ServiceNow, Zendesk or Xurrent — including their own residency options. We recommend confirming that the two regions you are connecting satisfy the same policy, since the connector will faithfully move data between whichever two you configure. Section 04 Sub-processor list Nil return 0 Sub-processors of customer data ADL Connect engages no third party to store, process or transmit your data. The processing chain contains only you, the platforms you already licence (Salesforce, Atlassian, Microsoft), and the target system you chose. Change notification This list is reviewed with each major release If the architecture ever introduced a sub-processor, we would publish it here and notify customers in advance Written confirmation of this nil return is available on request Note the second and fourth rows. Salesforce, Atlassian, Microsoft and your target system are not our sub-processors — you contract with them directly and they answer to you. Each publishes its own sub-processor list, and those lists already form part of your existing due diligence for those platforms. A sub-processor is a third party engaged by a processor to process personal data on its behalf. Because ADL Solution does not process your customer data in the first place — in any of our three marketplace apps — there is no processing to sub-contract, and therefore no sub-processors to disclose. 1The full processing chain, end to end Rather than leave the nil return unexplained, here is every party that can come into contact with data in an ADL Connect deployment, and the basis on which they do. 2Corporate systems (outside the product) For completeness — and because a thorough reviewer will ask — ADL Solution does run ordinary business systems for email, our website and support correspondence. These never contain your CRM records, but they may hold business contact details for the people who deal with us. We disclose them here so the picture is complete. If your procurement process requires the named vendors behind these corporate systems, we will provide them under NDA on request — they are simply not part of the product's data path, which is what a sub-processor disclosure is meant to cover. Parties in the data path Party Role Engaged by Sub-processor of ADL? Your organisation Controller — N/A Salesforce / Atlassian / Microsoft Hosting platform & processor You, under your own MSA/DPA No ADL Solution Software publisher You (licence) Not in data path Jira / Azure DevOps / ServiceNow / Zendesk / Xurrent Destination system You, under your own agreement No Any ADL-engaged cloud vendor — — None exist Scroll horizontally to see all columns Business-systems processors — corporate data only Purpose Data involved Customer CRM data? Business email & productivity Correspondence, business contact details Never Website & enquiry forms Name, company, email you submit to us Never Support ticketing Support requests you choose to send Not unless you attach it Marketplace licence management (Salesforce LMA, Atlassian & Microsoft partner portals) Org or site ID, app version, licence status Never Section 05 Marketplace review & vetting Passed Partner standing Approved Salesforce AppExchange partner Security review passed, actively maintained Listings public on all three marketplaces Distribution marketplace apps only ADL Connect on AppExchange Jira app on Atlassian Marketplace Azure DevOps extension on Visual Studio Marketplace Salesforce: the security review process On the report itself: Salesforce issues security-review results to the partner and does not publish a customer-facing certificate or pentest report for third-party apps. What we can provide on request is written confirmation of our partner status and review outcome, plus a completed security questionnaire for your file. If your process expects a downloadable third-party pentest report, tell us early — we would rather set that expectation correctly than have you discover it late in procurement. ADL Solution is an approved Salesforce AppExchange partner, and our managed package has successfully passed Salesforce's security review — a mandatory, code-level audit every package must clear to be listed, and re-clear to stay listed. Our Jira and Azure DevOps apps are listed on their own marketplaces under each vendor's separate vetting process, which we set out honestly below rather than implying one review covers all three. 1What the Salesforce review actually tests The AppExchange security review is materially stricter than a self-attestation. Salesforce inspects the package's source and its running behaviour against their published requirements, looking for the vulnerability classes that matter on their platform. This section describes the Salesforce managed package. 2What applies to each marketplace Review regimes differ by marketplace, so here is the position for each app — stated plainly, because a reviewer will check. Being straight about the difference. Salesforce’s security review is a code-level audit; Atlassian’s and Microsoft’s listing processes are vetting and policy compliance, not an equivalent source-code audit. Our Jira app is not currently Atlassian Cloud Fortified and is not enrolled in the Marketplace Bug Bounty. We would rather state that here than let a reviewer discover it and question everything else on this page. What is identical across all three is the architecture: none of them send your data to us. 3How your reviewer can verify this independently You do not have to take our word for it. A listing's presence on AppExchange is itself the evidence: Salesforce does not permit a managed package to be publicly listed unless it has passed review and continues to pass. All three listings are public and can be checked directly. Review status per app App Vendor review What that involves Status AppExchange managed package Salesforce security review Static analysis, dynamic testing & manual code audit; periodic re-review Passed Jira app (Atlassian Marketplace) Atlassian listing approval + security & privacy questionnaire Vendor vetting; completed questionnaire published on the listing Listed & completed Azure DevOps extension (Visual Studio Marketplace) Microsoft publisher verification & policy review Publisher identity verification; marketplace policy compliance Listed & verified Scroll horizontally to see all columns Review scope — Salesforce managed package Test type What it covers Status Static code analysis Full Apex/LWC source scanned for injection, unsafe DML and insecure patterns Passed Dynamic application testing Running package probed for XSS, CSRF, access-control and session flaws Passed Manual code review Human review against Salesforce's security requirements checklist Passed CRUD & FLS enforcement Verifies the app honours object and field-level permissions — the most common failure cause Passed Sharing model compliance Confirms record-sharing rules are respected, not bypassed Passed Authentication & secret handling OAuth flows and credential storage assessed Passed Periodic re-review Re-submission required on Salesforce's ongoing cycle to remain listed Maintained Section 06 Application security controls Platform-enforced Control inheritance Your MFA policy still applies Your IP restrictions still apply Your Shield encryption still applies Your event monitoring still sees the activity Your backup/retention covers connector objects On certifications: ADL Connect's assurance rests on the certifications of the platforms that host it — Salesforce, Atlassian and Microsoft, which cover the environments your data actually sits in — plus the AppExchange security review of our Salesforce code. We do not hold a separate SOC 2 Type II or ISO 27001 certificate in ADL Solution's own name, because we operate no infrastructure in the data path that such an audit would scope. We state this plainly rather than implying otherwise — if your policy has a hard certification requirement, let's discuss it before you invest time in the evaluation. Running natively means each ADL Connect app inherits its host platform's security model rather than reimplementing one. Your existing controls — Salesforce profiles, permission sets and sharing rules; Jira project permissions; Azure DevOps access levels; plus MFA, IP ranges and audit logging on each — continue to apply to everything the connector does. 1Access control Permission-set gated — users only reach connector functionality you explicitly grant. CRUD & FLS respected — the Salesforce package honours object and field-level security, verified in security review. Sharing rules honoured — record visibility follows your org's sharing model; the Jira and Azure DevOps apps act as the signed-in user, so they cannot surface records that user could not already open. Admin-defined scope — you choose which objects and fields are ever in scope for sync. 2Authentication & credentials OAuth 2.0 between systems, replacing basic auth and legacy tokens — with PKCE on the Azure DevOps extension. Named Credentials — secrets held by the platform, not in code or custom fields. No credential egress — your tokens are never transmitted to ADL Solution. Least privilege — we recommend a dedicated integration user scoped to the minimum needed. 3Transport & auditability TLS in transit for every callout from your org to your endpoint. Encryption at rest provided by Salesforce; compatible with Shield Platform Encryption. Sync audit trail written to custom objects inside your org, queryable and retainable by you. Allowlisted endpoints — outbound destinations are visible and controlled in Setup. 4Secure development & response Source control & review for all package code, with static analysis before submission. Versioned marketplace releases — upgrades are packaged and delivered through Salesforce, Atlassian or Microsoft, never pushed from ADL directly. Vulnerability reporting — email contact@adlsolution.com and we will acknowledge and triage promptly. Customer notification — where an issue affects deployed orgs, we notify affected customers directly. Section 07 Privacy, GDPR & data subject rights You stay in control Documents on request Completed security questionnaire (CAIQ-style) Written sub-processor nil return Confirmation of AppExchange partner status Architecture & data-flow statement Field-level sync scope for your config ADL Solution Privacy Policy Terms of Service Because the data never leaves your systems, responding to data subject requests does not involve us. Access, rectification, erasure and portability are all executed in the systems you already control — your Salesforce org, your Jira site and your Azure DevOps organisation. 1Handling data subject requests 2Retention & deletion ADL Solution retains no copy of your data, so there is nothing for us to delete at contract end and no deletion certificate needed for record content. Uninstalling an app removes it from that tenant — the managed package from your Salesforce org, the app from your Jira site, the extension from your Azure DevOps organisation. Your records remain yours, in your own tenants, governed by your own retention policy. 3Breach notification Since we hold none of your data, a compromise of ADL Solution could not expose your records. Incidents affecting Salesforce, Atlassian or Microsoft fall under those vendors' notification obligations to you under your own agreements. If we ever became aware of a vulnerability in any of our apps that could affect deployed tenants, we would notify affected customers directly and ship a patched version through the relevant marketplace. Who actions each right Right Actioned in ADL involvement Access / portability Your own tenants (Salesforce, Jira, ADO) None required Rectification Your Salesforce org (syncs onward) None required Erasure Your own tenants (Salesforce, Jira, ADO) None required Restriction of processing Disable the sync rule in Setup None required Objection Your own controller process None required Section 08 Security review questions, answered The questions that come up most often in vendor assessments of ADL Connect. Do you have a DPA we need to sign? For the data flowing through ADL Connect, the governing agreements are the DPAs you already hold with Salesforce, Atlassian and Microsoft. We do not process that data, so a separate processor DPA with us would have no data in scope. If your policy requires a signed instrument from every vendor regardless, we will sign a statement confirming the no-processing position and covering the limited business-contact data we do hold. Ask us and we will turn it around quickly. Can you confirm in writing that you have no sub-processors? Yes. We provide a signed nil return stating that ADL Solution engages no sub-processors for customer data, and explaining the architecture that makes that true. Section 04 of this page is the public version of that statement. Where is our data stored? In the data centres that serve your own tenants — Salesforce for your org, Atlassian for your Jira site, Microsoft for your Azure DevOps organisation. ADL Solution stores none of it, so we add no region to your assessment. Does ADL staff have access to our data? No — not by default and not by design. There is no ADL back end holding your records, and no standing access path into your Salesforce org, Jira site or Azure DevOps organisation. If you request hands-on support, you may choose to grant temporary, revocable access (for example Salesforce's "Grant Login Access" or a scoped sandbox user). That access is initiated by you, time-boxed by you, visible in your login history, and revocable at any moment. We never require it to run the product. Are you SOC 2 or ISO 27001 certified? ADL Solution does not hold a SOC 2 Type II or ISO 27001 certificate in its own name. Those audits scope a vendor's hosting environment and operational controls — and we operate no infrastructure in your data path for them to cover. The assurance that is in scope: the Salesforce platform's own certifications cover the environment your data actually resides in, and the AppExchange security review covers our code. We would rather tell you this directly than let a certification question surface late in procurement. What happens to our data if we stop using ADL Connect? Nothing leaves with us, because nothing was ever held by us. Uninstalling removes the app from that tenant. Your records — and the sync history written into your own custom objects — remain in your control, subject to your retention policy. How do we report a security vulnerability? Email contact@adlsolution.com with the details. We acknowledge reports promptly, triage them, and where an issue affects deployed tenants we notify affected customers and ship a patched version through the relevant marketplace. Do the Jira and Azure DevOps apps store data too? No. They follow the same model as the AppExchange package: the app installs into your own Jira site or Azure DevOps organisation and talks directly to your Salesforce org. Our Visual Studio Marketplace listing states it plainly — the extension is backend-less, and work item content and Salesforce data never transit our infrastructure. So the nil sub-processor return in Section 04 covers all three apps, not just the Salesforce one. Have the Jira and Azure DevOps apps had the same security review? Not the same one — and we would rather say so than blur it. Salesforce’s AppExchange security review is a mandatory code-level audit, and our managed package has passed it. Atlassian and Microsoft run their own listing approval, publisher verification and policy processes, which our apps have cleared, but those are vetting rather than an equivalent source-code audit. Our Jira app is not currently Atlassian Cloud Fortified and is not in the Marketplace Bug Bounty programme. Section 05 sets out exactly what applies where. The architecture — no ADL server, no data held by us — is identical across all three. Will you complete our vendor security questionnaire? Yes. Send it to contact@adlsolution.com. Most questions on a standard questionnaire resolve to "not applicable — no vendor-side processing", and we will answer each one explicitly rather than returning a blanket N/A. Need this in your procurement pack? We will complete your security questionnaire, provide a written sub-processor nil return, and confirm our AppExchange partner status and review outcome — usually within two business days. Request documentation Talk to our team