Salesforce Data Cloud and external company data

Salesforce has renamed Data Cloud as Data 360, so articles written before the change use the older name. This guide explains, from Salesforce's own documentation, how external company data such as Fokals can reach the platform, when to copy the data in and when to leave it where it is, and how to match company rows to your Account records. Every statement about Salesforce comes from its own pages, read on 4 October 2026 and linked below.

The name, and what the platform does

Salesforce's Data 360 page calls the product Salesforce Data 360, formerly known as Data Cloud, and its architecture guides use the new name. Its page on how it works describes four steps: connect data from many sources, harmonise it by mapping it to a standard data model, unify identities into profiles with matching and reconciliation rules, and activate the result inside Salesforce and on other platforms. The architecture guide names the layers that matter to a data team. Data lake objects hold the ingested data, and data model objects are created by mapping lake object fields to the standard Customer 360 data model.

Fokals is delivered direct, by REST API and as bulk files in JSON, JSON Lines or CSV, which your team brings into Data 360 with the platform's own loaders, by one of the routes below.

Three ways to bring company data in

Salesforce's integration patterns guide and its interoperability guide describe the routes. The table sets each beside what it asks of a team that licenses a daily feed.

Choose by cadence. Fokals tables are written once for each closed day or week and are not revised. The intent tables arrive weekly, the hiring tables daily and the technology tables daily to weekly, so a scheduled file load matches them. The interoperability guide lists real-time ingestion for sub-second needs and streaming ingestion in micro-batches every one to three minutes, and neither brings fresher data than a daily or weekly table holds.

Fokals exports are CSV, JSON or JSON Lines, so CSV is the format that matches the file route. You pull the export for a period, with the manifest that names its sources, period, label versions and licence, and put the file in your own bucket. Salesforce advises splitting data that exceeds the per-object limit into smaller files and several data streams, and an export by period gives you that split. Three habits save trouble:

• One key per row. A closed period is never revised, so a reload of the same file should replace rows and not add them. Build one key column from the grain in the data dictionary: company and day for Hiring Activity, company, topic and week for Intent Scores.
• JSON cells as text. CSV files carry lists and objects as JSON in a single cell, such as the evidence in Intent Scores. Map those fields as text and parse them downstream.
• A schema from a real file. Salesforce's guide describes a schema file with the column headers and a representative row. Take both from a sample file, so that the column names match the dictionary.

Copy in, or query in place

Salesforce's zero copy page describes zero copy as a data federation technology that lets Data 360 query external data without copying it, in two directions. Data in means external sources are queried live. Data out means other platforms can read what Data 360 produces. The interoperability guide sets out the trade-offs: ingestion copies the data in and supports central governance, live query gives the freshest read but depends on the performance of the source, caching suits repeated queries, and file federation reads object storage directly for large batch work.

For licensed company data the consequence is practical. If you have already loaded Fokals into a data warehouse for analysts, querying it in place avoids a second copy and a second load job. If the account-level signals must sit inside Data 360 to build segments, ingest them. Either way the licence still governs who may see the data and for what use. Fokals is licensed by written agreement for internal use, embedding in a product or redistribution, so settle which applies before you activate anything outside your organisation. The page on delivery describes the API and the bulk files.

Matching Accounts to Fokals companies

Data 360 has its own answer to matching. The architecture guide says its identity resolution supports individuals, accounts and households, applies match rules to records, and for accounts uses a model when it matches company names fuzzily. A ruleset suits records that carry no shared key.

Fokals data does share one, the company website, so a deterministic crosswalk is simpler and its errors are easier to audit. Build it before ingestion from the domains in Technology Stack, and load it as one more table.

with fokals_sites as (
  select distinct company_id, lower(domain) as domain
  from company_technologies
)
select
  a.account_id,
  f.company_id,
  'domain'     as match_method,
  current_date as matched_on
from sf_accounts a          -- your extract, with the website reduced to a bare domain
join fokals_sites f on f.domain = a.website_domain;

Three pitfalls decide whether the crosswalk can be trusted.

• Hierarchy. Your Accounts may be organised as parents and children, and a brand or subsidiary in the Fokals index carries the listing identifiers of its listed parent, so ISIN, LEI or FIGI cannot tell a child from its parent. Match each Account on the company ID and use the listing identifiers only to roll up.
• Many to one. Several Accounts can share one website. Decide whether a signal attaches to each Account or to the parent.
• Match rate. A domain join matches the Accounts whose website is in the Fokals company index, so read the match rate by segment before you build on it.

Measure the result with two numbers. The match rate is matched Accounts divided by Accounts that have a website, read by segment. The precision is the share of a hand-read sample of matches that are right. If you also run name matching in a ruleset, compare its matches with the domain matches before you activate anything on them.

What you can do once the data is in

The architecture guide describes what sits downstream of unified data. Calculated insights aggregate metrics on a schedule or in real time, segments turn profiles into audiences, and activation delivers segments to external endpoints. Acme Robotics, an illustrative company, could define a segment of Accounts for which the surge flag is true on one topic in Intent Scores and new postings in Hiring Activity rose over the last 28 days. It would ingest the two tables and the crosswalk and use the rule to feed a campaign list. To judge the rule, compare the share of segment Accounts that open an opportunity within 90 days with the same share among matched Accounts outside the segment.

The guide on prioritising accounts with intent scores covers how to weigh such rules, and the guide to joining licensed company data to CRM tables covers the same join in a warehouse. The mapping, relationship and segment screens are in Salesforce's own guides, and this guide stops where they begin.

How to read the data

Fokals is company-level data throughout, so it works at Account level: it enriches Account records and feeds account-level segments. Tables refresh daily or weekly, and every observation is dated and written once. Intent scores are evidence-backed: every score carries the dated signals behind it, and the intent dataset is built from what a company does in public, so a rep or a model reviewer can open the source of any score.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 4 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.