Your data never leaves your own systems.

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.

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.

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.

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.

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.

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.

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.

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.