Integrating Own with Salesforce: a backup is not a live sync

A restore of Account ran on Saturday morning over edits the sales team had made on Friday afternoon. The plan called the job a sync between the backup and the org, and it called the backup OwnBackup because that is what people still type. The new org already had accounts. The restore put Friday's copy back on top of them. Automation in the target sent mail. A field the new org does not have arrived blank. On Monday the two orgs disagreed, and the backup that was supposed to keep them aligned was the thing you needed in order to undo the restore. Nobody had named the object in a sentence a seller could read. Nobody had run the test on a record they could afford to lose.

That Saturday is the integration this page is about, and the first correction is that it is not a live sync. Salesforce completed the Own Company acquisition on 18 November 2024. People still search OwnBackup. Own Recover is now Salesforce Backup & Recover. Backup is a copy from a time you choose. A restore names the object and a test. A diagram that does not name the system, the object, and the failure is a poster. The build sits on the Own implementation page. The ownership story sits on what happened to Own. This page is the restore.

#The system

This page quotes the completion once: "Salesforce completed its acquisition of Own Company on November 18, 2024." Completion was 18 November 2024. The agreement was announced on 5 September 2024. The 5 September 2024 announcement said approximately $1.9 billion in cash, net of shares Salesforce already owned. That is the deal, not a licence and not an integration cost. Do not paste it into a cost per user. Do not drop the words "approximately" or "net of shares Salesforce already owned". Those words are part of the figure. Your fee is the contract in the drawer. If the contract is silent, write that your fee is not the announcement.

People still search OwnBackup. Keep OwnBackup in your notes so a search and a contract can find each other. Do not let the search name become a second product, and do not let it become a second system on the diagram. This page quotes the product line once: "Own Recover, ranked the #1 Enterprise SaaS Backup by G2, is now Salesforce Backup & Recover." Say Salesforce Backup & Recover in new documents. When a colleague searches OwnBackup, answer with the current name and the same scope. The search habit will outlast the rename. The scope should not drift to follow the habit.

The system is the backup, and the system is the org you would restore into. They are not one system. The org is the record. The backup is a copy from a time you choose. Salesforce owning the product does not decide which objects are in the job, or which org a restore may touch. A live sync would mean each save in one place appears in the other as it happens. That is not what a backup is. If a slide says the two orgs stay aligned because Own is connected, the slide has renamed a copy as a pipe.

This page will not invent a connector edition or an API name. It will not invent an RPO. A recovery point is a number you can show from the job you actually run, or it is absent. A workshop guess is not an RPO. Write "not stated" and describe the test instead. This page does not give Backup & Recover an end date. A rename from Own Recover is not a retirement.

#The object

A restore names the object. Account is a fair example when the fear is lost accounts, and a poor example when the fear is lost files and you restore accounts anyway because they are first in the list. Write the object. Write whether related records come with it. A restore of Account that also restores contacts, cases, and files is a different job from a restore of Account alone. If you do not know, the object is not named yet. Do not start Saturday.

Name the org that receives the restore. Production, a named sandbox, or a full copy you built for the test are different targets. "The new org" is not a name when two projects are cutting over. The Saturday failure wrote into an org that already had Friday's edits. The target was live enough to send mail. That target needed a sentence: this restore may overwrite these objects, and here is who approves it.

Name what the job holds, in a list a person can check. If the list is "everything", you will restore objects the new org has already changed, and you will discover the blanks where a field does not exist. A field the target does not have does not become a successful mapping because the backup has a value. Write the miss as a finding before you run the job, not as a surprise on Monday.

The backup is not the system of record. Do not migrate production data into Own as if Own were the new CRM. Decide what must be recoverable. The object on the restore is the object you are willing to test, not the object that makes the diagram look complete.

#The failure when the restore does not land

The failure this page stands on is a restore that lands on the wrong terms. It overwrites live edits. It sends mail from the target. It blanks a field the target does not have. Or it does not land at all: the job fails, and the only copy you trusted is the one you cannot read. Write which of those you will rehearse. "The sync failed" is the wrong sentence, because there is no live sync to fail.

A test is part of the object, not a footnote. Pick a record you can afford to lose or a target that is not production. Restore that object. Read it as the seller, and as the admin who must explain a blank. Compare it to the live record you did not mean to touch. If they differ, say whether the difference is the point of the restore or a defect. A restore you have not compared is a hope.

Do not invent an RPO to make the failure look measured. "We lost four hours" is a story from a test you ran, or it is a story you must not print. This page will not supply the number. If a vendor slide has a number, ask which job, which object, and which day you proved it. Until then the failure plan is the test, the approver, and the way you stop a restore that has started to send mail.

Stopping is part of the failure. Someone must be able to halt the job when the target starts doing work you did not intend, such as email. Write the name. A restore that can only be watched by the person who sold it will run through Saturday night because that person is not in the room.

The deal figure does not describe this failure. Approximately $1.9 billion is not how you buy a safer restore. It is not the cost of the Saturday mistake. Keep it in the history note.

#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. Two clouds, a lightning bolt, and the word sync do not say which backup, which object, or what happens when the restore overwrites Friday. Draw the backup under its current name, Salesforce Backup & Recover, and add OwnBackup only so a searcher can match the old word. Draw the target org. Draw the object. Draw the test and the overwrite.

Do not draw a live pipe between two orgs and label it backup. That drawing is the mistake in the opening. Backup is a copy from a time you choose. A pipe that keeps two systems identical is a different product and a different design. This page does not name that product. Do not invent one to fill the arrow.

Do not put the $1.9 billion figure on the diagram as a licence, a capacity, or an integration cost. It is the deal. A poster that uses it as a tier has turned a corporate close into a rate card.

#What you settle before anyone restores

Write five lines before Saturday. The product name you will use in new documents, and the search name people still type. The target org. The object, and what related records come with it. The test record or the non-production target. The person who may approve a restore that can overwrite, and who may stop it.

Then say what you are not buying. You are not buying a live sync. You are not buying an RPO this page does not state. You are not buying a licence equal to the deal. You are not buying a new CRM called Own. This page does not give the product an end date.

The implementation page is where objects, a drill, and the refusal to treat backup as a migration are taken apart. What happened to Own is where 18 November 2024, the September figure, and OwnBackup as a search habit are kept. Use those pages when the meeting argues about the price. Bring the meeting back to the object you would restore.

Agree who may add an object to the job. A new object is a new test. The poster does not grow because a list said everything.

#A test you can run

Restore one named object into a target that is not the org your sellers are editing, unless you have a written approval that names the overwrite. Read a record you changed on purpose before the restore. Say whether the restore removed that change. If it did, you have learned what Saturday will do. Write it down. If the target sent mail, stop and treat that as the failure, not as a side effect.

Read a field the target does not have. Confirm you know what arrives blank. Do not discover that on Monday in production.

Search the documents for OwnBackup. Where a new document still uses only that name, add Salesforce Backup & Recover and keep the search word in parentheses if a colleague needs it. Do not add a second system. Confirm nobody has typed the deal figure into the statement of work as the integration cost.

The integration is ready when a new administrator can see the backup, the target, the object, and the test without calling it a sync. If the page still says OwnBackup keeps two orgs aligned, send it back. The completion on 18 November 2024 did not turn a copy into a pipe.