Which connector version should I choose?

Choose **v2** for a new pipeline. You decide which fields become columns, and on a [destination that supports merge](/docs/destinations/#merge-support) each run loads only the records that changed since the previous one. **v1** exists so that pipelines created before the version choice appeared keep working exactly as they did.

Why are Id, CreatedDate and SystemModstamp already ticked and greyed out?

Renta uses Id to identify a record, CreatedDate to partition the table, and SystemModstamp to detect changes. Without them the incremental sync cannot work, so they always land in the table, even on destinations where the run is a full reload.

Can one pipeline export several objects?

No. One pipeline exports one object into one table. Create a pipeline for every object you need. They can share the same connection, destination, and schedule.

Can I change the version of an existing pipeline?

Yes. Open the pipeline settings and pick another **Connector version**. The set of columns changes with the version, so the next run reloads the whole object.

How do I connect a sandbox org?

Set **Environment** to **Sandbox** before you click **Log in to your Salesforce account**. Salesforce opens the login page of test.salesforce.com instead of the production one. A sandbox refresh invalidates the authorization, so reconnect the source after you refresh the sandbox.

What happens to records deleted in Salesforce?

A table that Renta reloads in full drops them on the next run. A table that Renta syncs incrementally keeps them: Salesforce leaves deleted records out of its responses, so Renta never learns about the deletion.

Salesforce

Renta exports Salesforce objects to your data warehouse: leads, accounts, contacts, opportunities, cases, and any other standard or custom object of your org.

One pipeline exports one object into one table. A row holds the fields of one record, custom fields included, as they are in Salesforce at the moment of the run.

Authentication

Renta uses OAuth to authenticate with Salesforce. You will be redirected to Salesforce to sign in and grant Renta access to your org.

Before the login you choose the Environment: Production for a regular org, Sandbox for a sandbox org, which Salesforce serves through test.salesforce.com. On the consent screen Salesforce asks for full access and for the right to perform requests at any time. Renta uses this access to read object metadata and records and writes nothing back.

Your credentials are encrypted in transit and at rest, and never stored in Renta's application database. You stay in control and can revoke access from the Connected Apps OAuth Usage page in Salesforce Setup at any time.

Connect Salesforce as a source

Go to the CatalogStep 1

In the Renta console, open Connections > Catalog in the left sidebar.
Open the CRM category and click the Salesforce card.

Salesforce card in the CRM category of the Renta connection catalog

Choose the environment and start the authorizationStep 2

Pick the Environment of the org you connect, then click Log in to your Salesforce account. Renta hands you over to Salesforce.

Environment dropdown set to Production and the login button on the Salesforce connection page

Name the connection and saveStep 4

Finish the setup:

Source name.
A label for this connection, used only inside the Renta console.
Access granted.
The Salesforce user the authorization came from.

Click Save to finish.

If the authorization later stops working, for example after the Salesforce password changed or the connected app was revoked, click Re-authorize on this connection. It refreshes in place and the pipelines built on it keep running.

Source name field and the granted Salesforce account on the connection form

Verify the connectionStep 5

The connection appears in the Sources list with the Active status and is ready for pipelines.

Sources list with the new Salesforce connection in the Active status

Create a Salesforce pipeline

Select Salesforce as the sourceStep 1

In the left sidebar, click New pipeline. Keep the ETL tab selected, find Salesforce under Already connected, and click Next step.

Select a source step of the pipeline wizard with Salesforce under Already connected

Select the connectionStep 2

Choose the Salesforce connection you created and click Next step. The card shows the Salesforce user behind it, which matters when several people connected different orgs.

Select your Salesforce connection step with the authorized user on the card

Select a destinationStep 3

On the Destination step, pick the warehouse that receives the data and click Next step.

Select a destination step with the connected warehouses

Select the destination connectionStep 4

Choose the destination connection and click Next step.

Pipeline configuration

The last step of the wizard holds every setting in one scrolling form.

Salesforce object

The object decides which records the pipeline exports.

The dropdown lists the standard and custom objects of your org by their labels. Pick one. To export several objects, create a pipeline for each of them.

Connector version

The connector version decides which fields the table gets and how Renta keeps the table up to date.

Version	Description
v2	You choose the fields to export. On a destination that supports merge the table is synced incrementally: after the first run, each run loads only the records created or changed since the previous one. Number fields arrive as numbers.
v1	The legacy behaviour. Every field of the object is exported, and every run reloads the whole table. Text, boolean, date, datetime and currency fields keep their types, every other field arrives as text.

New pipelines start on v2. Pipelines created before the version choice appeared run on v1 until you switch them in the pipeline settings. Switching changes the set of columns, so the next run reloads the whole object.

Parameters

Tick the Salesforce fields that become columns of the destination table. The picker appears for v2 only.

The list holds every field of the selected object, custom fields included, with the Salesforce data type under each name. Click Select All to take every field.

Id, CreatedDate and the field Salesforce updates on every change of the record (SystemModstamp on most objects) arrive pre-selected and cannot be cleared. Renta needs them to identify a record and to detect changes.

Integration and table name

Name the pipeline in Renta and the table in your destination.

Integration name and Table name fields in the pipeline settings

Integration name.
The display name of the pipeline in the Renta console.
Table name.
The table in your destination. Keep the generated name or type your own.

Schedule

The schedule decides how often the pipeline runs. Renta reads the times you set here in UTC.

Schedule type	Description
Manual	The pipeline runs only when triggered from the Renta console or through the API.
Daily	The pipeline runs once a day at the specified update time.
Interval	The pipeline runs at specified time intervals.
Cron Expression	The pipeline runs on a schedule defined by a cron expression.

For Daily schedules, set the Update time (the exact time each run starts), then click Create pipeline.

Update time dropdown and the Create pipeline button

Renta also supports API triggers and orchestrators such as Apache Airflow, Dagster, and Prefect. See the scheduling documentation for details.

The pipeline appears in the Pipelines section under the ETL tab, together with the destination table name, run progress, and the number of extracted rows.

Pipelines list with the Salesforce pipeline and its destination table name

Sync strategy

How Renta synchronizes the table depends on the connector version, the destination, and the object.

Strategy	Applies to	Description
Incremental (merge)	v2 pipelines with a destination that supports merge, for objects that have `Id` and `CreatedDate`	The first run loads the whole object. Each later run fetches the records created or changed since the previous run, filtering by `SystemModstamp` (or `LastModifiedDate` where the object has none), and upserts them into the destination by `Id`. The table is partitioned by `created_date`, the day of `CreatedDate`, which Renta adds as an extra column.
Full reload	v1 pipelines, v2 pipelines with any other destination, and objects without `Id` or `CreatedDate`	Every run replaces the whole table with the current state of the object in Salesforce.

Incremental sync needs a destination that supports merge. See which destinations support it. With other destinations a v2 pipeline reloads the selected fields of the whole object on every run.

Records deleted in Salesforce stay in an incrementally synced table. Salesforce leaves deleted records out of its responses, so Renta never learns about the deletion. A table that Renta reloads in full drops them on the next run.

Frequently asked questions

Ready to get started?

Build your data pipeline today or get a personalized demo. Start free!

Need help?

Get expert support to ensure your project succeeds. We're here to help!

Feature requests?

Help shape our product! Share your ideas for new features and integrations.