Salesforce Data Connector for Google Sheets: How to Use It

Reviewed by Miles Carter – Practical AI Reviewer

Connecting Salesforce to Google Sheets can be surprisingly useful when the people who need to work with CRM data do not want to spend every reporting session inside Salesforce. Google’s Salesforce Connector lets you bring Salesforce reports or queried records into a spreadsheet, analyze them with familiar Sheets functions, refresh selected data later, and in some situations send edited information back to Salesforce. The important part is understanding that this is a live connection to business data rather than a one-time CSV export, because some actions can create, update or delete real Salesforce records.

Google currently lists the add-on in the Workspace Marketplace as Salesforce Connector, while its help documentation still refers to Data connector for Salesforce in the Google Sheets menus. Those names describe the same Google-developed add-on, and the current Google Salesforce Connector listing confirms that it can import Salesforce reports, run custom queries or SOQL, insert or update Salesforce records, refresh data and delete Salesforce records. It is currently listed as free of charge, which is worth separating from similarly named third-party products such as G-Connector.

If your question is broader than spreadsheets, the guide to Salesforce and Google Workspace integration covers the wider relationship between Salesforce and Google’s productivity environment. This article stays narrower and more practical. The goal is to show exactly how the Google Sheets connector works, where it is useful, what can go wrong, and when a spreadsheet starts becoming the wrong place to manage Salesforce data.

What Can the Salesforce Connector Actually Do in Google Sheets?

The connector does considerably more than copy a Salesforce report into a spreadsheet. Google’s official instructions for importing, editing and syncing Salesforce data with Google Sheets describe separate workflows for importing reports, importing records through a query builder or SOQL, updating Salesforce records from edited spreadsheet data, inserting new records, performing an insert-or-update operation, refreshing previously imported data and deleting Salesforce records. That makes the add-on closer to a lightweight Salesforce data-management interface than a normal spreadsheet import feature.

The distinction matters because each operation carries a different level of risk. Reading a report into Sheets is relatively low risk because Salesforce remains unchanged, while an update can alter existing CRM information and a delete can remove records from Salesforce. I would therefore separate spreadsheets intended for reporting from spreadsheets intended for write-back rather than letting one workbook become a casual editing surface for everything.

Is the Salesforce Connector for Google Sheets Free?

Google’s own Salesforce Connector is currently listed in the Google Workspace Marketplace as free of charge. It is developed by Google and the listing shows support for Google Sheets as well as a newer Salesforce smart-chip capability in Google Docs. This is the connector covered throughout this guide.

That answer becomes confusing because several third-party products also use names such as Salesforce Connector, G-Connector or Salesforce Sync. Those applications can provide additional scheduling, data-loading or collaboration features, but their pricing and limits are controlled by their own developers rather than Google. If you are following instructions for Google’s connector, confirm that the Marketplace listing identifies Google as the developer before comparing its functionality with another add-on.

The older version of this page mixed Google’s connector with G-Connector and XL-Connector, which made the pricing discussion contradictory. That distinction is removed here because a reader trying to install Google’s add-on should not have to work out which product each paragraph is actually describing.

How to Install the Salesforce Connector in Google Sheets

Start from a Google Sheet rather than from Salesforce. According to Google’s current Data connector for Salesforce setup instructions, open a spreadsheet and choose Extensions > Add-ons > Get add-ons, then search for Data connector for Salesforce. Select the Google-developed Salesforce Connector and complete the Marketplace installation and permission process.

The permission screen deserves more attention than most quick tutorials give it. The current Salesforce Connector Marketplace permission listing says the add-on can view and manage spreadsheets in which it is installed, connect to an external service, display content in sidebars, run when you are not present, see your primary Google Account email address and access several other pieces of account information required by the integration. That unattended-execution permission is especially relevant if you intend to create scheduled refreshes.

If you use a company-managed Google Workspace account and cannot install the connector, the problem may be administrative rather than technical. Google explains that Workspace administrators can block Marketplace installations, limit users to approved applications or install an application centrally for the organization. The Google Workspace Marketplace installation guidance explains the messages users see when an administrator has blocked or restricted an application.

How to Connect the Add-On to Salesforce

After installation, open the spreadsheet and choose Extensions > Data connector for Salesforce > Login to Salesforce. Google then asks you to continue, grant the required access, choose the Salesforce environment you want to use, authorize the connection and sign in with your Salesforce credentials. The authentication happens through the connector workflow rather than by putting a Salesforce password into spreadsheet cells.

Choose the environment carefully. If you are experimenting with record updates, inserts or deletes, test the process against an appropriate non-production Salesforce environment where your organization provides one rather than learning bulk write-back behavior on live customer records. A simple report import is much safer to validate than an operation capable of modifying hundreds of CRM rows.

Once authorization succeeds, reopen the connector from Extensions > Data connector for Salesforce > Open. A sidebar appears on the right side of Google Sheets and becomes the main interface for reports, imports, updates, refreshes and deletions.

How to Import a Salesforce Report Into Google Sheets

For an existing Salesforce report, choose Reports in the connector sidebar. Search for the report you want, then decide whether its results should enter the current sheet or a new sheet. Once you select the destination and retrieve the data, the report output becomes normal spreadsheet data that can be used with formulas, filters, pivot tables, charts and other Sheets features.

Using an existing report is usually the easiest starting point because the report logic has already been defined inside Salesforce. Someone has normally chosen the fields, filters and business interpretation before the data reaches Google Sheets. This reduces the risk of recreating reporting logic differently in two places.

The weakness is that the spreadsheet can easily look more current than it really is. A nicely formatted dashboard does not tell the reader when the underlying Salesforce values were last retrieved. Put a visible Last refreshed area near any management-facing summary so nobody makes a decision based on an old extract that merely looks live.

When Should You Use a Salesforce Report Instead of a Custom Import?

Use a Salesforce report when the required data already exists in a reliable report and the spreadsheet’s purpose is analysis, presentation or collaboration. This keeps business logic closer to Salesforce and avoids maintaining a second set of filters that nobody remembers six months later. It is particularly sensible for recurring pipeline, activity, account and operational summaries.

A custom import is more useful when the existing Salesforce report contains too much information, omits required fields or cannot easily express the exact dataset you want to analyze. Google’s connector allows custom imports through its visual query interface as well as through SOQL. Google’s current help documentation says the import interface supports adding up to five source objects, fields and filters, so complicated multi-entity reporting should be planned rather than treated as an unlimited spreadsheet query surface.

When the requirement becomes highly relational, extremely high volume or dependent on near-real-time synchronization, a spreadsheet connector may stop being the right architecture. The convenience of Sheets should not become the reason the organization builds a fragile data-integration process around a workbook.

How to Import Salesforce Data With the Query Builder

Open the connector sidebar and choose Import instead of Reports. Search for the Salesforce object and fields you need, then add filters so the returned records are limited to the business question you are trying to answer. Google also supports SOQL for users who need more control over the query.

Start narrower than you think you need. Pulling every available field from a large Account, Contact, Lead or Opportunity dataset makes the sheet harder to understand and increases the chance that sensitive or irrelevant information will be shared accidentally. An analysis workbook usually needs a carefully selected slice of Salesforce rather than a mirror of the CRM database.

I also prefer keeping the Salesforce record ID in any dataset that could later be updated. Names, company names and email addresses can change or duplicate, while an ID gives the workflow a stable record reference. Removing identifiers because they look unattractive can make later reconciliation considerably harder.

How to Use SOQL With the Salesforce Google Sheets Connector

SOQL stands for Salesforce Object Query Language. Salesforce’s SOQL guidance for querying Salesforce records describes it as a query language designed specifically for retrieving Salesforce data, and its structure will feel familiar to anyone who has used SQL even though the two languages are not identical. The connector lets you enter SOQL when the visual import builder is not precise enough.

A simple account extract could look like this:

SELECT Id, Name, Industry, Owner.Name, LastModifiedDate
FROM Account
WHERE Industry != null
ORDER BY LastModifiedDate DESC
LIMIT 500

That query deliberately selects only several useful fields and limits the result. The exact field names available in your organization can differ because Salesforce supports custom objects and custom fields, while access also depends on the Salesforce account being used. Copying a query from another company without adapting its schema is therefore one of the easiest ways to create an immediate error.

A pipeline query might instead look like this:

SELECT Id, Name, Account.Name, StageName, Amount, CloseDate, Owner.Name
FROM Opportunity
WHERE IsClosed = false
ORDER BY CloseDate ASC
LIMIT 500

SOQL becomes especially useful when you know the object and fields you need and want precise filtering, sorting or relationship traversal. Salesforce’s SOQL Builder documentation describes the same core concepts through SELECT, FROM, WHERE, ORDER BY and LIMIT, which makes it a useful reference when a query becomes more complex.

Why I Would Always Use a LIMIT While Testing

A first query should prove that the object, fields and filters are correct before it tries to retrieve the complete operational dataset. A LIMIT gives you a small result set that is easier to inspect, makes mistakes more obvious and avoids turning every query change into a large spreadsheet refresh. Once the logic is validated, increase the amount deliberately according to the actual reporting requirement.

Filtering also improves interpretation. A sheet containing every opportunity ever created is rarely as useful as one containing the active opportunities relevant to the current forecast or sales period. The goal is to retrieve the smallest dataset that can answer the decision in front of you.

Can You Edit Salesforce Data Directly From Google Sheets?

Yes, and this is the point where I would stop treating the connector as a reporting convenience. Google’s current instructions allow users to edit imported spreadsheet values and then use Update in the connector sidebar to transfer changes back to Salesforce. The connector can perform Insert, Update, or Insert or Update, with a results column used to show the outcome of the operation.

That capability can be valuable when a sales-operations team needs to correct a controlled set of records more efficiently than opening each one individually. It can also become dangerous when a broadly shared spreadsheet is mistaken for a harmless reporting document. Any sheet with Salesforce write-back should be owned and permissioned differently from a workbook that people casually sort, copy and edit for analysis.

Before sending changes back, save an untouched reference copy or re-import the source into a separate tab. Compare the intended edits against the source, check formulas that might have changed values unexpectedly and verify that your key columns still point to the correct Salesforce records. Spreadsheet convenience should shorten reviewed bulk work rather than remove the review step.

Insert, Update and Insert-or-Update Are Different Operations

Insert creates new Salesforce records from the spreadsheet data. Use it only when those rows genuinely represent records that do not already exist, because an accidental repeat can create duplicates that later need to be reconciled.

Update changes existing Salesforce records. This operation is usually safer when you have retained the Salesforce IDs from the original import and know exactly which fields are intended to change.

Insert or Update combines both possibilities and can be useful for maintaining a dataset where some records already exist while others need to be created. Because that operation has more possible outcomes, validate the matching logic and examine the connector’s results carefully before using it at scale.

Can the Connector Delete Salesforce Records?

Yes. Google’s help documentation explicitly warns that the add-on can delete the Salesforce records represented by the rows you select in Sheets. The process requires importing the relevant data, choosing Delete in the sidebar, selecting the intended rows and columns, identifying the Salesforce object and selecting the primary-key column before confirming the deletion.

I would reserve this operation for controlled administrative work. A spreadsheet makes bulk selection extremely easy, which is exactly why deletion deserves more friction than the interface naturally provides. Filter the records first, make a reviewed backup of the identifiers, have another person verify the selection when the data is important, and confirm that the Salesforce object being targeted is the one you intended.

Salesforce does provide recovery for many soft-deleted records. The Salesforce Recycle Bin guidance explains that users can view and restore eligible records in the Recycle Bin, while administrators can manage the wider organizational Recycle Bin. Salesforce also states that deleted records generally remain there for 15 days, but that recovery path should be treated as a safety net rather than permission to test deletion casually.

How Do You Refresh Salesforce Data in Google Sheets?

Open the Salesforce Connector sidebar and choose Refresh. You can refresh data manually when you need an updated snapshot, and Google also documents an automatic schedule for previously imported reports. The current choices listed in Google’s help are every 4 hours, every 8 hours or every 24 hours.

That means the standard Google connector should not be described as a real-time synchronization system. A four-hour minimum scheduled interval can be perfectly adequate for a morning management dashboard or a daily operations sheet, yet it may be unacceptable for a process that must react to customer or transaction changes within minutes. The refresh requirement should therefore be decided before the connector is chosen.

For a recurring spreadsheet, I would place refresh information directly in the workbook rather than hiding it in documentation. Include who owns the connection, what Salesforce source it uses, how often it refreshes and what someone should do when the refresh fails. A recurring report without a visible owner eventually becomes a report everyone assumes somebody else is maintaining.

Can You Refresh More Often Than Every Four Hours?

Google’s documented scheduled intervals for this connector are 4, 8 and 24 hours. If the business genuinely needs hourly or more frequent retrieval, do not try to disguise that requirement as a spreadsheet-reporting problem. Evaluate a different connector, an API-based process or another integration architecture that has scheduling appropriate to the operational requirement.

Third-party Salesforce spreadsheet connectors sometimes advertise more flexible schedules, but that introduces another vendor, another authorization model and potentially another subscription. The extra capability should solve a real business requirement rather than being installed simply because a shorter interval sounds better.

Does Sharing the Google Sheet Also Share the Salesforce Data?

Once Salesforce information has been imported into spreadsheet cells, the sharing permissions on the Google file become critically important. Google’s Drive sharing documentation explains that a file owner can grant Viewer, Commenter or Editor access and can also make a file available through broader link sharing where organizational policy permits it. Someone who can view the spreadsheet can therefore view the Salesforce data that has already been copied into that spreadsheet, regardless of whether that person normally browses the same information inside Salesforce.

This is one of the most important practical risks of the connector. Salesforce may have carefully designed profiles, roles, sharing rules and field-level controls, but exporting permitted data into a broadly shared spreadsheet creates another place where that information now lives. Before connecting a sensitive Salesforce report, check the Google Sheet’s current sharing state and the permissions inherited from its Drive folder.

I would also reduce Editor access where possible. An analysis audience may only need Viewer permission, while the person maintaining formulas may need Editor access and the person authorized to write data back to Salesforce should be an even narrower group. One workbook does not need to give every collaborator every possible action.

The Salesforce Connector Is Useful, but Sheets Should Not Become a Shadow CRM

A spreadsheet often begins as a reporting convenience and slowly becomes an unofficial operating system. Users add manual columns, color codes, notes, formulas and their own interpretations of Salesforce stages until nobody is sure whether Salesforce or the spreadsheet contains the current truth. The connector can make that drift worse because refreshing one part of the workbook creates the appearance that the entire workbook is synchronized.

Decide which fields belong to Salesforce and which spreadsheet columns are temporary analysis. If users need to write a new operational field repeatedly, that may be evidence that the field belongs in Salesforce rather than in column Q of a shared workbook. If people constantly reconcile two versions of the same value, the process needs redesign rather than another formula.

The best spreadsheet connection keeps Salesforce authoritative while using Sheets for analysis, controlled bulk work or communication. Once the spreadsheet starts owning customer status, approvals, operational history or workflow state that should exist in CRM, the convenience has become technical debt.

A Safe Workbook Structure for Salesforce Data

I prefer separating source data from analysis rather than letting formulas, manual notes and imported records share one tab. Create one tab for the connector output, leave its structure as stable as possible and build analysis, pivots and presentation tabs separately. This reduces the likelihood that a refresh overwrites something a user believed was permanent.

For write-back workflows, use an even clearer separation. Keep the imported original dataset, a reviewed edit area and a results area so the team can see what changed and whether Salesforce accepted each operation. The extra structure feels slower on the first day but becomes invaluable when someone asks which 300 records were changed last Thursday.

Also document the primary identifier being used. A visible Salesforce ID column may be ugly to a casual spreadsheet user, but it can be one of the most valuable columns when a bulk change must be audited, reversed or investigated.

Why a Refresh Can Break a Carefully Formatted Spreadsheet

A connected range is data first and presentation second. If a refresh changes the number of returned rows or replaces values that formulas assume will remain stationary, downstream calculations can shift unexpectedly. This becomes more likely when users mix connector output, hand-entered values and formulas in the same area.

Build calculations against stable columns and keep presentation layers separate from the raw import where possible. Named ranges, pivot tables and dedicated summary tabs can make the workbook easier to maintain, but they still need testing after the connector source changes. A Salesforce administrator adding or renaming a field can create consequences far beyond Salesforce when multiple spreadsheets depend on that field.

The same principle applies to reports. Changing the Salesforce report’s filters or columns may alter the dataset retrieved by the sheet. Treat the source report as part of the spreadsheet’s dependency chain rather than an unrelated CRM asset.

What Permissions Does the Google Salesforce Connector Request?

The current Marketplace listing shows that the Google-developed connector requests access to manage spreadsheets in which it is installed, connect to external services, run third-party sidebar content, execute while the user is absent and view account information such as the primary Google Account email address. Those permissions make sense for an add-on that needs to access Salesforce and perform scheduled activity, but they should still be reviewed as part of the organization’s normal third-party application governance.

A company using restricted Workspace settings may require an administrator to approve the connector before users can install it. That can feel inconvenient to someone trying to build a quick report, yet centralized approval is reasonable when a connector can move customer and commercial data out of a CRM and into a collaborative spreadsheet environment. Ease of installation should not override data-governance requirements.

On the Salesforce side, use an account with the access required for the intended task rather than defaulting to the most powerful administrator account available. Reporting, updating and deletion have very different risk profiles, and a connection intended only for reporting should not automatically be treated like an administrative data-loader session.

What Should You Do Before Allowing Write-Back?

Test one object and a very small group of records first. Confirm which identifier is used, which spreadsheet columns correspond to Salesforce fields, what happens to blank values and how validation rules or required fields behave when the update reaches Salesforce. Keep the test narrow enough that every outcome can be inspected manually.

Then test failure. Deliberately use a record that violates a known validation rule or an obviously invalid value in a sandbox or safe test environment and see how the results are returned. A workflow is not ready merely because successful rows work – operators need to understand how failures are displayed and how they will be corrected.

Finally, decide who is permitted to initiate the write-back. Many people may legitimately need to see the spreadsheet, while only one or two people need authority to push a bulk update into the CRM. That separation is often more important than the formula design.

Common Reasons the Salesforce Connector Does Not Work

The Add-On Does Not Appear Under Extensions

First confirm that it has actually been installed for the Google account currently open in Sheets. A user with several Google accounts can easily install the add-on under one profile and then work in a spreadsheet under another. If the Marketplace says the application is blocked or not allowed, your Workspace administrator may need to approve or deploy it.

Google’s Marketplace guidance explicitly distinguishes user-installed applications from applications installed or restricted by administrators. That makes an administration message different from an authentication failure. Reinstalling the connector repeatedly will not solve a domain policy that is intentionally blocking it.

The Salesforce Login Fails

Check that the correct Salesforce environment was chosen and that the Salesforce account itself can sign in normally. Organizations using custom authentication, network restrictions, SSO or stricter security policies may need an administrator to review how the OAuth connection is being handled. Avoid weakening security controls simply to make a spreadsheet connection succeed.

If normal manual imports work but scheduled refreshes fail, treat those as separate execution contexts rather than assuming the connector is completely authenticated. Scheduled activity must be able to run without the user sitting in front of the spreadsheet, which is one reason the Marketplace permission list includes the ability to execute while the user is not present.

A Salesforce Field Cannot Be Found

Confirm the field’s API name rather than relying only on its label. Custom Salesforce fields commonly end in __c, and an administrator can change a human-readable label without changing the underlying API name. The connected user also needs to be able to access the object and field being requested.

This is particularly important with SOQL. A query that works in one Salesforce organization may fail immediately in another because custom schemas are different. Build the query against your own organization’s objects rather than treating an example query as universally portable.

The Query Returns Too Much Data

Reduce the fields, add a WHERE clause and introduce a LIMIT while testing. Pulling less data improves usability and also forces the reporting requirement to become more precise. A spreadsheet containing ten useful columns and 500 relevant rows is often more valuable than one containing 80 columns and every record the account can see.

If the business genuinely requires large-scale extraction or repeated bulk processing, reassess the architecture. Sheets is an excellent analytical interface, but it is still a collaborative spreadsheet rather than a data warehouse or integration platform.

The Spreadsheet Shows Old Values

Check whether the data has actually been refreshed. The presence of the connector does not mean every cell remains continuously synchronized with Salesforce. Manually refresh when current information is required, or configure one of Google’s supported 4, 8 or 24-hour schedules for the applicable recurring report.

Also check whether the source report or query itself still represents the intended business logic. A successful refresh of the wrong filter is technically fresh data and still produces the wrong answer.

Google’s Connector vs a Third-Party Salesforce Sheets Connector

Google’s connector is an attractive starting point when the requirement is straightforward: import a Salesforce report, run a focused query, make controlled updates and refresh data at one of the supported intervals. It is free according to the current Marketplace listing and comes directly from Google, which removes one pricing question from the evaluation. Its simplicity is part of the attraction.

A third-party connector becomes worth evaluating when the requirement exceeds those boundaries. More frequent scheduling, advanced history, specialized bulk-loading behavior, additional data-management functions or other operational features may justify another product. For example, the current Marketplace listing for G-Connector advertises scheduling options beyond the cadence documented for Google’s connector, but that should be compared as a separate commercial product rather than described as though it were the built-in Google solution.

I would not change connectors merely because another one has a longer feature list. First identify the exact limitation creating a problem, then compare whether the alternative removes that limitation without creating larger security, licensing or support concerns.

When Google Sheets Is the Right Place for Salesforce Data

Sheets works well when the goal is ad hoc analysis, controlled collaboration, a management report, a temporary reconciliation exercise or a modest bulk-editing job that benefits from spreadsheet visibility. People can inspect many records at once, use formulas they already understand and communicate around one shared dataset. That can be faster than building a permanent Salesforce interface for a short-lived requirement.

It also works well as the presentation layer for an existing Salesforce report when the sales or operations team wants to combine CRM data with calculations that do not belong permanently inside Salesforce. In this scenario Salesforce remains the source and Sheets becomes a flexible analysis surface. The distinction is clear and manageable.

The fit gets weaker when the workbook becomes mission critical, heavily automated, extremely large, difficult to permission or responsible for coordinating several systems. Those requirements normally deserve an integration or application architecture designed for reliability rather than a spreadsheet that has gradually acquired production responsibilities.

When I Would Stop Using the Connector

I would move away from a spreadsheet-centered approach when the business requires near-real-time synchronization, strong transaction guarantees, complicated multi-system orchestration or unattended processing that must recover predictably after failures. Those are integration requirements rather than reporting requirements. A connector designed around a user-facing spreadsheet should not be forced to behave like enterprise middleware.

I would also reconsider the architecture when many people begin editing the same Salesforce-backed workbook for operational purposes. The more a team depends on formulas, colors and manually interpreted spreadsheet columns to tell them what to do next, the harder it becomes to identify the authoritative business state. CRM is valuable partly because customer data and process rules have a controlled home.

The final warning sign is fear of refreshing. If users hesitate to refresh because they are unsure what will be overwritten, displaced or recalculated, the workbook has mixed imported data and human-owned data too tightly. Separate the layers or move the workflow into a system designed to own it.

A Practical Setup I Would Use

For a recurring Salesforce management report, I would create a dedicated Google Sheet owned by a business account rather than an individual’s temporary personal workbook. One tab would contain connector-managed source data, another would contain calculations, and another would contain the executive presentation. The source tab would include the Salesforce ID and enough metadata to troubleshoot discrepancies without exposing unnecessary fields.

I would then configure the slowest refresh interval that still supports the decision. A daily report does not need a four-hour schedule merely because four hours is available, while a report used during the business day may justify the shorter interval. Fewer unnecessary refreshes also make ownership and troubleshooting easier to understand.

For any write-back process, I would use a separate workbook or clearly isolated workflow with limited Editor access. The person initiating updates would compare the edited records against an original import and review the connector’s result column afterward. That small amount of discipline preserves most of the convenience without turning Salesforce updates into uncontrolled spreadsheet edits.

Should You Use the Salesforce Connector for Google Sheets?

Yes, when the problem is fundamentally spreadsheet-sized. Google’s connector gives Salesforce users a practical way to import reports, retrieve custom datasets, perform controlled data maintenance and keep recurring Sheets reports refreshed without building a custom integration from scratch. For analysts, sales operations and managers, that can remove a surprising amount of repetitive export-and-copy work.

The bigger decision is how much authority the spreadsheet should receive. Reporting is easy to justify, updating needs review, and deletion should be deliberately restricted. As soon as the workbook becomes a second CRM, a transaction-processing system or a multi-system synchronization layer, the architecture has moved beyond what made the connector useful in the first place.

The most reliable rule is to keep Salesforce authoritative and let Google Sheets do what spreadsheets are good at: analysis, controlled collaboration, temporary transformation and clearly governed bulk work. When that boundary remains visible, the connector can be extremely useful without creating another source of truth that the organization eventually has to reconcile.

Frequently Asked Questions