Metrica Power BI Connector for Salesforce
Metrica Software Inc.
Last Updated: June 18th, 2026
This Data Processing Agreement (“DPA”) forms part of, and is incorporated by reference into, the End User License Agreement between Metrica Software Inc. (“Metrica”, “we”, or “us”) and the customer (“Customer”, “you”) governing the Power BI Connector for Salesforce (the “App” or “Connector”). This DPA applies to the extent Metrica processes Customer Personal Data on Customer’s behalf in connection with the Connector. Capitalized terms not defined here have the meanings given in the EULA.
In the event of a conflict between this DPA and the EULA regarding the processing of Customer Personal Data, this DPA controls.
1. DEFINITIONS #
“Customer Personal Data” means Personal Data that Metrica processes on Customer’s behalf in connection with the Connector, as described in Annex I.
“Data Protection Laws” means all laws and regulations applicable to the processing of Personal Data under this DPA, including, as applicable, the EU General Data Protection Regulation 2016/679 (“GDPR”), the UK GDPR and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection, and applicable U.S. state privacy laws.
“Personal Data”, “Controller”, “Processor”, “Data Subject”, “process/processing”, “Personal Data Breach”, and “Supervisory Authority” have the meanings given in the GDPR (or the equivalent terms under other applicable Data Protection Laws).
“Salesforce Org” means the Customer’s own Salesforce organization, licensed by the Customer directly from Salesforce, in which the Connector is installed and runs.
“Salesforce Business Data” means the Customer’s records, business data, and other content (for example, Accounts, Contacts, Opportunities, and custom objects) residing in the Salesforce Org.
“OAuth Authorization Proxy” means the stateless auxiliary service described in Section 4.2 and Annex II, used only during initial OAuth authorization.
“Error Telemetry” means the diagnostic exception reporting described in Section 4.2 and Annex I.
“Standard Contractual Clauses” or “SCCs” means the standard contractual clauses for the transfer of Personal Data to third countries approved by the European Commission (Decision 2021/914), Module Two (Controller to Processor).
“Sub-processor” means any third party engaged by Metrica to process Customer Personal Data.
“License Data” has the meaning given in the EULA (name and email of the license holder and associated license metadata).
2. ROLES AND SCOPE #
2.1 Roles. For Customer Personal Data processed in connection with the Connector, Customer is the Controller (or a Processor acting on behalf of a third-party Controller) and Metrica is the Processor. Where Customer is itself a Processor, Metrica is a sub-processor and the instructions referenced in this DPA are those of Customer’s own controller.
2.2 In-Org Processing; Limited Metrica-Side Processing. The Connector is a Salesforce managed package that runs inside the Customer’s Salesforce Org. All configuration, token, and audit data that the Connector creates is stored in the Salesforce Org, on Salesforce infrastructure, under the Customer’s own Salesforce agreement, data-residency, and backup arrangements. Metrica does not host, receive, or have access to that data; in particular, the encryption key used by the Connector is held in a Protected Custom Setting that is inaccessible to the Customer’s users outside the Org and to Metrica staff. Accordingly, the only processing of Customer Personal Data that occurs on Metrica-controlled infrastructure is (a) the OAuth Authorization Proxy and (b) Error Telemetry, each described in Section 4.2 and Annex I. The processor obligations in this DPA apply to that Metrica-side processing; for data processed within the Salesforce Org, the Customer’s own agreement with Salesforce governs hosting, residency, and security.
2.3 License Data. Metrica processes License Data as an independent Controller for licensing, billing, and support purposes, as described in Metrica’s Privacy Policy. License Data is outside the scope of Metrica’s Processor obligations under this DPA, except that Metrica will process it in accordance with applicable Data Protection Laws.
2.4 Scope of Processing. The subject matter, duration, nature and purpose of the processing, the types of Customer Personal Data, and the categories of Data Subjects are described in Annex I.
3. PROCESSING OF CUSTOMER PERSONAL DATA #
3.1 Documented Instructions. Metrica will process Customer Personal Data only on documented instructions from Customer, including with regard to international transfers, unless required to do otherwise by applicable law (in which case Metrica will, where legally permitted, inform Customer of that requirement before processing). Customer’s instructions are set out in this DPA, the EULA, and Customer’s configuration and use of the Connector. Customer’s instructions will comply with Data Protection Laws.
3.2 Salesforce Business Data Is Not Stored. Metrica does not copy, cache, or persist Salesforce Business Data at any point. The OData feed exposed to Power BI is a live passthrough: every Power BI refresh re-queries the Salesforce Org live through the Connector’s REST endpoint inside the Org, executing a SOQL query under the requesting user’s own permissions (`WITH USER_MODE`, enforcing the user’s standard CRUD, field-level security, and sharing), and streams the result back without storing the rows. The only by-product recorded from an export is aggregate metadata (row counts, duration, status) written to the in-org history objects, not the exported records themselves. Metrica does not use Salesforce Business Data, or any Customer Personal Data, to train, fine-tune, or improve any artificial intelligence or machine-learning model, or for any purpose other than providing and supporting the Connector and as instructed by Customer.
3.3 Confidentiality. Metrica will ensure that persons authorized to process Customer Personal Data are bound by appropriate obligations of confidentiality.
3.4 Customer Responsibilities. Customer is responsible for the accuracy, quality, and legality of Customer Personal Data, for establishing a lawful basis for the processing, and for its configuration choices (including which Salesforce objects, fields, and recipients it exposes through the Connector, and which users it authorizes through the Connector’s custom permissions).
4. SECURITY #
4.1 Security Measures. Metrica will implement and maintain the technical and organizational measures set out in Annex II, designed to ensure a level of security appropriate to the risk, taking into account the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing.
4.2 Hosting and Data Residency. All data the Connector persists is stored within the Customer’s own Salesforce Org, whose hosting, region, and residency are determined by the Customer’s agreement with Salesforce. The only Metrica-controlled infrastructure in the path is:
– (a) the OAuth Authorization Proxy — a stateless AWS Lambda function fronted by Amazon API Gateway in Metrica’s AWS account (United States, region `us-east-1`), used only during a user’s initial OAuth authorization redirect. It persists nothing, has no database or cache, never receives Salesforce access or refresh tokens, never receives the PKCE code-verifier, and never sees Salesforce Business Data; per request it observes only a single-use OAuth authorization code and an opaque `state` value. A Customer may bypass it entirely by registering its own Salesforce Connected App (“direct mode”). After initial authorization, all exports, token refreshes, and other traffic flow directly between the Salesforce Org and Power BI, with no Metrica infrastructure in the path.
– (b) Error Telemetry — the Connector reports unhandled exceptions to an error-monitoring service (Sentry) for engineering diagnostics. The payload may include the Salesforce user id and org id, the exception type and stack trace, and an optional transaction label; it does not include Salesforce Business Data, field values, tokens, or encryption keys. A Customer may disable this entirely by clearing the telemetry DSN in its Org.
5. SUB-PROCESSING #
5.1 Authorized Sub-processors. Customer provides general authorization for Metrica to engage the Sub-processors listed in Annex III, namely the cloud provider for the OAuth Authorization Proxy and the error-monitoring provider for Error Telemetry.
5.2 Sub-processor Obligations. Metrica will impose on each Sub-processor data protection obligations no less protective than those in this DPA and remains responsible for each Sub-processor’s performance of its obligations.
5.3 Changes. Metrica will inform Customer of any intended addition or replacement of a Sub-processor with reasonable advance notice, giving Customer the opportunity to object on reasonable data-protection grounds. If Customer reasonably objects and the parties cannot agree on a resolution, Customer may terminate the Connector subscription as its exclusive remedy.
6. ASSISTANCE TO CUSTOMER #
6.1 Data Subject Requests. Taking into account the nature of the processing, Metrica will assist Customer by appropriate technical and organizational measures, insofar as possible, to respond to requests from Data Subjects exercising their rights under Data Protection Laws. Because the configuration, token, and audit data resides in the Customer’s own Salesforce Org, the Customer can locate, export, rectify, and delete that data directly using Salesforce’s tools and the Connector’s own administration functions. If Metrica receives a request directly, it will, unless legally prohibited, promptly inform the Data Subject to direct the request to Customer and notify Customer.
6.2 Erasure. Erasure of in-org Personal Data is performed by the Customer within the Salesforce Org (using Salesforce’s tools together with the Connector’s delete and revoke functions). Personal Data contained in Error Telemetry is retained only for the error-monitoring provider’s standard retention period and ages out automatically; the Customer may prevent further telemetry by clearing the DSN (Section 4.2(b)).
6.3 DPIAs and Consultation. Metrica will provide reasonable assistance to Customer with data protection impact assessments and prior consultations with Supervisory Authorities, taking into account the nature of the processing and the information available to Metrica.
7. PERSONAL DATA BREACH #
Metrica will notify Customer without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data processed on Metrica-controlled infrastructure (the OAuth Authorization Proxy or Error Telemetry). The notification will describe, to the extent known, the nature of the breach, the likely consequences, and the measures taken or proposed to address it. Metrica will provide reasonable cooperation and information to assist Customer in meeting its breach-notification obligations. Incidents affecting data within the Salesforce Org are addressed under the Customer’s own agreement with Salesforce.
8. INTERNATIONAL TRANSFERS #
8.1 In-Org Data. Data stored within the Salesforce Org is hosted in the region determined by the Customer’s agreement with Salesforce; any transfer of that data is governed by the Customer’s own arrangements with Salesforce and not by Metrica.
8.2 Metrica-Side Processing. To the extent the OAuth Authorization Proxy or Error Telemetry involves a transfer of Customer Personal Data from the European Economic Area, the United Kingdom, or Switzerland to a country that does not provide an adequate level of protection, the SCCs are incorporated into this DPA by reference, with Metrica as data importer and Customer as data exporter, completed as follows:
– Module Two (Controller to Processor) applies (or Module Three, Processor to Processor, where Customer acts as a Processor);
– the optional docking clause applies;
– for Clause 9, Option 2 (general written authorization) applies, with the notice period in Section 5.3;
– for Clause 17, the governing law is the law of Ireland;
– for Clause 18, the courts of Ireland have jurisdiction;
– Annexes I, II, and III to this DPA populate the corresponding Annexes of the SCCs.
8.3 UK and Swiss Transfers. For UK transfers, the UK International Data Transfer Addendum to the SCCs applies; for Swiss transfers, the SCCs apply with the adaptations required by Swiss law.
9. AUDITS #
Metrica will make available to Customer the information reasonably necessary to demonstrate compliance with this DPA and Article 28 GDPR, primarily through current third-party certifications or audit reports for the infrastructure underlying the OAuth Authorization Proxy and Error Telemetry (such as SOC 2 or ISO 27001) and Metrica’s responses to a reasonable written data-protection questionnaire no more than once per twelve (12) months. The parties agree that provision of this documentation will ordinarily satisfy Customer’s audit rights. An on-site inspection may be conducted only (a) where required by a Supervisory Authority, (b) following a confirmed Personal Data Breach affecting Customer Personal Data, or (c) where Metrica fails to provide the documentation described above; and then only by an independent third-party auditor mandated by Customer and bound by confidentiality, on at least thirty (30) days’ prior written notice, during business hours, at Customer’s expense, subject to Metrica’s security and confidentiality requirements, limited to information relevant to Customer, and without access to other customers’ data or to any data center operated by a Sub-processor.
10. DELETION AND RETURN #
10.1 In-Org Data. Because all configuration, token, and audit data resides in the Customer’s own Salesforce Org, the Customer controls its retention and deletion directly. Uninstalling the managed package removes the Connector’s custom objects and settings from the Org in accordance with Salesforce’s package-uninstall behavior; the Customer may also delete individual records at any time. Metrica does not hold a copy to return or delete.
10.2 Metrica-Side Processing. The OAuth Authorization Proxy persists no data. Personal Data contained in Error Telemetry is retained only for the error-monitoring provider’s standard retention period and is then deleted; the Customer may stop further telemetry at any time by clearing the DSN.
11. LIABILITY #
Each party’s liability arising out of or related to this DPA is subject to the limitations and exclusions of liability set out in the EULA, and any reference to a party’s aggregate liability includes liability under this DPA and the EULA combined. Nothing in this DPA limits liability that cannot be limited under Data Protection Laws.
12. GENERAL #
12.1 Term. This DPA takes effect when the EULA takes effect and continues for as long as Metrica processes Customer Personal Data, after which the deletion and return obligations apply.
12.2 Precedence. This DPA supplements the EULA. In case of conflict regarding Customer Personal Data, this DPA controls; where the SCCs apply, the SCCs control over this DPA to the extent of any conflict.
12.3 Governing Law. Except where the SCCs or Data Protection Laws require otherwise, this DPA is governed by the governing law of the EULA.
ANNEX I — DESCRIPTION OF PROCESSING
A. List of Parties
Data Exporter (Controller): Customer, as identified in the EULA / order.
Data Importer (Processor): Metrica Software Inc., 9353 Tangerine Coast Dr, Boca Raton, FL 33434-5919, USA. Contact: legal@metricasoftware.com.
B. Description of Processing
*Categories of Data Subjects:* Customer’s authorized users of the Connector and of Power BI; individuals identified in the Salesforce records the Customer elects to expose through the Connector; and individuals named in Customer’s sharing/recipient lists.
Personal Data stored within the Customer’s Salesforce Org (on Salesforce infrastructure; not hosted by or accessible to Metrica):
1. Configuration data — data-source name and description, selected objects and fields, and filter expressions (the Customer’s choices about what to expose to Power BI).
2. Identity and sharing data — the owner/creator/modifier of each data source (Salesforce user ids in standard `OwnerId` / `CreatedById` / `LastModifiedById` fields) and sharing-list entries (Salesforce user/group ids).
3. Personal Access Token records — the SHA-256 hash of each token only; the plaintext is generated server-side in Apex, returned to the user once at issuance, and never retrievable thereafter.
4. Salesforce OAuth tokens — per-user access and refresh tokens, encrypted at rest with AES-256 using a key held in a Protected Custom Setting inaccessible to the subscriber’s users outside the Org and to Metrica.
5. History / audit records — data-source change history, token issue/revoke/expire history, and export history (actor, data-source label, object name, status, row count, timestamps). These capture how much was exported, never the exported records.
6. Transient authorization session — a per-authorization PKCE record, deleted on first callback and otherwise purged on a daily schedule.
Personal Data processed on Metrica-controlled infrastructure:
– OAuth Authorization Proxy (AWS, `us-east-1`): per initial-authorization request, a single-use OAuth authorization code and an opaque `state` value (the subscriber’s Site callback URL plus a one-time nonce). Stateless; nothing is stored; no tokens, PKCE verifier, or business data are seen.
– Error Telemetry (Sentry): Salesforce user id and org id, exception type and stack trace, the Apex class/method, and an optional transaction label. No Salesforce Business Data, field values, tokens, or encryption keys are included. Disableable by clearing the DSN.
*Categories of Personal Data — processed transiently only (not stored):* Personal Data contained in Salesforce Business Data returned in response to a Power BI refresh, streamed live from the Salesforce Org to Power BI under the requesting user’s own permissions and never copied, cached, or persisted by Metrica.
*Special categories of data:* None intended. Customer is responsible for not exposing special-category data through the Connector except as permitted by applicable law.
*Nature and purpose of processing:* Provision of the Connector — enabling the Customer to query its Salesforce Org live and load the resulting data into Microsoft Power BI for analytics and reporting, to manage configuration, authentication, sharing, and audit within the Org, and (on Metrica-controlled infrastructure) to facilitate initial OAuth authorization and to monitor errors.
*Duration / Retention:* In-org data is retained and deleted under the Customer’s control (Section 10.1); export history is removed after approximately one month by a scheduled job, while data-source and token history are retained until the Customer deletes them; the transient authorization session expires within minutes. Error Telemetry is retained for the error-monitoring provider’s standard retention period. The OAuth Authorization Proxy retains nothing.
ANNEX II — TECHNICAL AND ORGANIZATIONAL MEASURES
Architecture. The Connector is a Salesforce 2nd-Generation managed package installed from the AppExchange and executing inside the Customer’s own Salesforce Org. All persistent data resides in the Org as standard Salesforce custom objects and custom settings. The only Metrica-controlled infrastructure is the stateless OAuth Authorization Proxy (AWS, `us-east-1`) and the Error Telemetry pipeline.
Encryption in transit. Traffic between Power BI and the Connector runs over Salesforce-terminated HTTPS/TLS (Salesforce Sites and standard `*.salesforce.com` endpoints). The OAuth authorization redirect through the proxy is HTTPS end-to-end.
Encryption at rest. Salesforce-platform encryption at rest applies to every custom object and custom setting. In addition, the Connector encrypts the stored Salesforce OAuth tokens with AES-256; the per-org encryption key is held in a Protected Custom Setting and is therefore inaccessible to anyone outside the Org, including Metrica.
Per-org isolation. Each Salesforce subscriber Org is an independent Salesforce tenant; the Connector executes inside that tenant, and one subscriber’s records cannot be queried from another’s Org.
Per-user authorization. Sensitive actions are gated by two custom permissions (admin access; export/authenticate access). User-facing Apex uses `WITH USER_MODE` SOQL and `as user` DML, enforcing the running user’s standard CRUD, field-level security, and sharing. Power BI authentication validates the presented Personal Access Token against its stored SHA-256 hash and then runs the export under the token owner’s own Salesforce OAuth grants, so it cannot return rows the user could not read directly.
Token handling. Personal Access Tokens are stored only as a SHA-256 hash of a 256-bit random value; the plaintext is shown once at issuance and never retrievable thereafter. Salesforce OAuth tokens are AES-256 encrypted at rest with the key described above and exist in plaintext only in transient request variables. PKCE is required on every OAuth flow; the code-verifier is generated server-side, stored against a one-time nonce, never transmitted to the browser or the proxy, and deleted on first callback.
OAuth Authorization Proxy. Stateless; no database or cache; per request observes only a single-use authorization code and an opaque `state`; never receives tokens, the PKCE verifier, or business data; validates that the return URL is a Salesforce-owned domain before redirecting; and is fully bypassable via direct mode.
Error Telemetry. Exception reports may include the Salesforce user id and org id and diagnostic detail, but never business data, field values, tokens, or keys, and can be disabled by clearing the DSN.
ANNEX III — SUB-PROCESSORS
The Customer’s Salesforce Org and Microsoft Power BI are the Customer’s own environments and are not Sub-processors of Metrica; data stored within the Salesforce Org is governed by the Customer’s own agreement with Salesforce.
