# Integrating Heroku with Salesforce: the app is not a custom object

Heroku was acquired in 2010 and is still a separate platform. A sandbox does not clone it. An app is not a custom object.

**Published:** 2026-03-31
**Canonical:** https://synconai.com/integrating-heroku-with-salesforce
**Author:** SynconAI Architecture Team

## In short

Heroku was acquired in 2010 and is still a separate platform. It is not Data 360. A Salesforce sandbox does not clone Heroku. An app on Heroku is not a Salesforce custom object. Name the system, the object the app may read or write, and the failure when the call does not land.

## Sources

- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > As of October 14, 2025, Data Cloud has been rebranded to Data 360.

## What to take away

- Heroku was acquired in 2010. It is still a separate platform. It is not Data 360.
- A Salesforce sandbox does not clone Heroku. The app stays where you deploy it.
- An app on Heroku is not a Salesforce custom object. Name the object the call may touch.
- A diagram that does not name the system, the object, and the failure is a poster.

## The guide

A customer portal on Heroku showed a price the opportunity does not store. The seller on the phone quoted it. The opportunity still held last month's figure. A ticket then said to rebuild the portal as a Salesforce tab before the quarter closed, because the acquisition was in 2010 and a slide had drawn the app inside Data 360. The portal has its own deploy and its own on-call rota. Rebuilding it as a tab would drop the screen customers already use and keep a logo. The release was paused, which was the right pause, for the wrong reason. The call from the app to the record had not landed. The slide had moved a box.

That portal is the integration this page is about. Heroku was acquired in 2010. It is still a separate platform. It is not Data 360. A Salesforce sandbox does not clone Heroku. An app on Heroku is not a Salesforce custom object. Name the system, the object the app may read or write, and the failure when the call does not land. A diagram that skips those is a poster. The build sits on [the Heroku implementation page](/heroku-salesforce). The ownership story sits on [what happened to Heroku](/what-happened-to-heroku). This page is the call between the app and the record.

## The system

Salesforce bought Heroku in 2010. Heroku is still a separate developer platform. You still deploy the app where it runs. A Salesforce org is a different runtime. The acquisition changed the owner of the product. It did not, on the facts this page uses, turn the app into a set of CRM objects, and it did not move the app into the org because the vendor is the same.

People mix the app into Data 360 because a slide has one cloud and too many names. The help page this guide cites states a rename. This page quotes it once, and only to say Heroku is not Data 360: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." The sentence does not mention Heroku. It does not say a Heroku app became a Data 360 pipeline. It does not say the 2010 deal was revised on 14 October 2025. Put Data 360 on its own line if you use it at all. Leave Heroku on the 2010 line, still a separate platform.

Name the system. The system is the app, in the environment you deploy, with an owner for that deploy. "Heroku" as a logo is not enough when you have more than one app. Write the app's name as the team says it. Write who is on call when it is down. The Salesforce org is the other system, and only for the object you are about to name. Do not call the whole org the integration.

A Salesforce sandbox does not clone Heroku. Refreshing the sandbox copies Salesforce metadata and, depending on the type, some CRM data. It does not copy the app, the app's data store, or the app's address. Anyone who says the sandbox now contains the portal should open the sandbox and try to load it. The absence is the finding. You point the app at that sandbox on purpose, with credentials that are not a personal login, when you mean to test. A refresh that leaves the app pointed at production will write a test into the live org. That is an incident, not a convenience.

This page will not invent an API name, a middleware SKU, or a price. The cited sentence does not publish a Heroku licence fee. It does not name a connector edition. If a proposal adds one, ask them to point at a sentence. When they cannot, strike the line and keep the app where it runs.

## The object

An app on Heroku is not a Salesforce custom object. The screen, the route, and the app's own store are not rows you create by refreshing an org. If the app must read or write Salesforce, name the object. Opportunity is a fair example when the portal must show the figure the seller also sees. A custom object is allowed when you can say who reads it. "The app" is not the object on the Salesforce side. "Sync" is not an object.

Write the direction. Read is not write. A portal that displays a price from the opportunity is a read of named fields. A portal that lets a customer change a date is a write to a named field. Do both only when you have written both, including what happens when they disagree. The phone call in the opening was a read of a figure the opportunity does not store. That figure lives in the app. Say so. Do not let the seller quote it as if it were the record.

Write the field that joins the app's user or order to the Salesforce record. An email address can collide. An id a person can point at is better. When the join misses, the app must not show a neighbouring customer's price. That miss is a failure, not a fuzzy match you hope will be close enough.

Write the fields the app may change, if it may change any. A status a customer can set is different from an amount only finance may set. The integration identity must not be able to write the amount just because it can read the opportunity. Permission is the control. A comment in a ticket does not close the field.

The app's own store remains an object you own as well, if the price the seller quoted lives there. Name it. Say whether Salesforce is allowed to ignore it. A design that pretends the only object is the opportunity will keep producing the phone-call failure.

## The failure when the call does not land

The call does not land when the portal shows a figure the record does not have, when the record never receives the customer's change, or when the app is pointed at the wrong org. Each is different. Write the one this portal will meet: the seller and the customer are looking at two prices, and here is who is told.

Say what the seller does in that hour. They quote the opportunity, and they say the portal may be ahead or behind. They do not invent a third price to split the difference. They do not rebuild the portal as a tab because the call failed. A tab is a different product shape. It is not a retry.

A shared channel that receives stack traces is not the failure design. Name the person on the app's rota, and the person who owns the Salesforce object. They are often different people. A page that lists one owner for both will approve a rebuild neither of them asked for.

Do not describe the miss as a Data 360 outage. The quoted sentence is a rename. It is not the portal's health check. Do not invent a daily cap to explain a missed write. This page states no ceiling. If the customer's change is missing on the record, find the object, the field, and the org the app addressed.

Stopping the write is part of the plan. Someone must be able to halt the app's writes without deleting the app. Customers may still need to read. Read and write fail separately. Write both switches down, with names.

## A diagram that omits three names is a poster

A diagram that does not name the system, the object, and the failure is a poster. A cloud labelled Heroku and Data 360, with an arrow into "Salesforce", does not say which app, which object, or what the seller quotes when the prices disagree. Draw the app. Draw the object. Draw the disagreement, and the person who is told.

Do not draw the app as a custom object inside the org. That drawing is the rebuild ticket, and the rebuild is not the integration. Keep the app in its own box. The arrow is the call, and only for the fields you named.

Do not put Data 360 in the Heroku box. The quote exists so you can say Heroku is not Data 360. If Data 360 is a real source for something else in the programme, give it another sentence and another owner. It is not the explanation for a portal price.

Cross out every other app on the account. This project integrates one app, or it integrates none until you pick. An estate poster can live in an appendix. The build follows the page with three names.

| What you name | A design says | A poster says |
| --- | --- | --- |
| System | The Heroku app and its deploy owner | Heroku, inside Data 360 |
| Object | The Salesforce object and the fields | The app as a custom object |
| Failure | Two prices, and who the seller trusts | Rebuild it as a tab |
| Sandbox | The app pointed at the sandbox on purpose | The refresh cloned Heroku |
| Direction | Read, write, or both, written separately | Sync |

## What you settle before the app calls the org

Write five lines before anyone connects them. The app and who deploys it. The Salesforce object and the fields. The direction. The join, and what happens on a miss. The person who is told when the portal and the record disagree.

Then say what you are not buying. You are not buying a clone of the app inside a sandbox. You are not buying a custom object that replaces the portal. You are not buying a Data 360 pipeline under a Heroku label. You are not buying a price this page does not state. This page does not give Heroku an end date. The 2010 acquisition was not a shutdown. Leave the app where it runs until a written replacement exists and customers can use it.

[The implementation page](/heroku-salesforce) is where the refusal to rebuild the app as a tab is taken apart. [What happened to Heroku](/what-happened-to-heroku) is where 2010, the separate platform, and the refusal to invent a purchase price are kept. Use those pages when the meeting argues about the acquisition. Bring the meeting back to the two prices.

Agree who may point the app at a new org. A sandbox refresh is not permission. The re-pointing is a named step, done on purpose, and reversed when the test is over.

## A test you can run

Point the app at the sandbox on purpose. Read one opportunity as the customer would, and as the seller would. The figures they are allowed to see should match the fields you named. A figure that exists only in the app should be absent from the seller's quote, or labelled as the app's figure in the script the seller uses.

Then force the failure. Stop the call, or point a test app at an org that does not contain the record. The seller's script should be sayable without a slide. Restore the call. Confirm you did not write a test price into production. If you did, the app was never pointed at the sandbox. That is the finding.

Confirm a sandbox refresh did not bring the app with it. Open the sandbox. The portal should be absent. The app should still be at its own address. If a proposal claims otherwise, ask to be shown the clone. Do not rebuild the portal while you wait.

:::warn
A diagram that does not name the system, the object, and the failure is a poster. A Salesforce sandbox does not clone Heroku. An app on Heroku is not a Salesforce custom object. Heroku is not Data 360.
:::

The integration is ready when a new developer can see the app, the object, the direction, and the person who handles two prices, without asking who drew the cloud. If the page still says to rebuild the portal as a tab, send it back. The acquisition in 2010 kept a separate platform. It did not land the customer's price on the opportunity for you.

## Questions

### Does a Salesforce sandbox clone Heroku?

No. A sandbox copies Salesforce metadata and, depending on type, CRM data. It does not clone a Heroku app, its data store, or its address. Point the app at that sandbox on purpose when you mean to test.

### Is Heroku the same product as Data 360?

No. Heroku was acquired in 2010 and is still a separate platform. The cited sentence says Data Cloud was rebranded to Data 360. This page uses that sentence only to keep the names apart. It does not mention Heroku.

### Is an app on Heroku a Salesforce custom object?

No. The app stays where you deploy it. If it must read or write Salesforce, name the object and the fields. A tab that replaces the portal is a different build, not the result of the 2010 acquisition.

### What is the failure when the call does not land?

The portal and the record show different figures, or a customer's change never reaches the object you named. Write who the seller trusts in that hour. Do not invent a third price, and do not treat a rebuild as a retry.

### Which page covers the build, and which covers the acquisition?

The implementation page covers keeping the app where it runs. The what-happened page covers 2010, the separate platform, and the refusal to invent a purchase price. This page is the app, the object, and the two prices.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce development (https://synconai.com/salesforce-development).