Use Cases

Due to corporate merger, divestiture or realignment of business units, or testing needs, data in one or more Salesforce.com orgs must be…

Cloned
One organization splits into two or more business units or companies, but both want all the data Frequent Salesforce sandbox refreshes are needed by developers for testing. The automated Salesforce refresh can only be done on 30-day intervals.
Split
One organization splits into two or more companies or business units, with each receiving only their portion of the data. A global organization wishes to separate business units into separate systems, but also create a combined org with all the data.
Merged
Corporate acquisition of another company who uses Salesforce, or another CRM. When an Enterprise decides to merge all its business units into one org, and keep a combined structure and data.

√ Relational Junction for Salesforce is natively designed for all three use cases.

Conversion Window

One time migration with planned outage of Salesforce.com usage

  • Requires weekend shutdown with no Salesforce.com updates
  • Duration of shutdown depends on data volumes, excellent
    preparation by testing the migration multiple times
  • This is the easy way, where you only convert the data once,
    and have the luxury of a planned outage.

Phased approach, with both systems being used while the migration happens

  • Used when we can’t meet the conversion window due to volume constraints.
  • Used when the business doesn’t have a single cutoff date.
  • Don't have the luxury of shutting down Salesforce usage for a weekend.
  • Both orgs are being synced for a period of time, due to needs of the business to maintain both systems until a business-driven cutoff date.

√ Relational Junction for Salesforce is natively designed for both scenarios

Salesforce Org Clone

One organization splits into two or more business units or companies, but both want all the data

  • Prepare a list of objects with the hierarchical order using –checkGlobal command
  • Request Salesforce.com turn on “Preserve Dates” feature for the duration of the project. This preserves the original CreatedDate field
  • Prepare for the handling of recursive relationships provided by the -checkGlobal command to get a rigorous list of all relationships where a record points to another record of the same type, such as Accounts with Parent Accounts
  • Turn off sharing rules in target org for faster load performance
  • Run SQL scripts against the tables for objects that can be uploaded, setting the control field in each table for “Insert to Salesforce” (DELETE_FLAG=’I’)
  • Download source org into a database. This schema will be used only by the conversion process, in addition to the regular schema used for day-to-day purposes

Identify all circular (recursive) relationships

  • Obtain recursive relationships, such as Contact.ReportsToID, Account.ParentID from the -checkGlobal report
  • Create LEGACY_ID columns to remember the original IDs of the parent objects and of the relationship foreign keys, so we can re-parent the children with SQL after the first pass is done.

Build recursive relationships

  • Update the table with SQL, put the new ID into the Parent ID using LEGACY_ID as a lookup and set the DELETE_FLAG control field to ‘U’ for Update.
  • Upload objects with circular relationships, setting only the Parent ID where Parent ID is not null

Load all data to Salesforce

  • Run –setGlobal on all objects to be loaded
  • Upload objects with recursive relationships without the Parent ID
  • Child objects will be re-pointed to the new org’s Salesforce ID’s using patented technique of database triggers and supporting indexes
  • Turn on sharing rules

If cloning into a partially populated org…

  • A config-only Sandbox has Users, Products, and various other objects pre-populated. 
    This actually makes it a bit harder, since we have to figure out what the new Salesforce ID is for the same instance of each record.
  • We can generally use the name of the User or Product to match the source, and create a cross-reference lookup table to obtain the new Salesforce ID’s from the target org.
  • Get a list of objects pre-populated in the new org. These will not be migrated, but will be downloaded from the new org to the conversion schema.
  • A map of the new conversion schema ID’s to the operational schema ID’s must be created for each object downloaded from new org.
  • A database function is created for each map and is used in ETL steps to assign correct new IDs.
  • The tables of existing new org objects are renamed and their counterparts are ETL copied from the operational schema to the conversion schema as their original names.
  • An ETL job is created and run that updates the IDs in the operational copied tables from the renamed new org tables using the ID maps.
  • If there are ongoing ETLs from the operational schema to the conversion schema, the mapping functions will be used in all steps for objects that have foreign keys.

If clone is subset of production org…

  • The criteria of what subsetting is required must be specified for every production object. Typically you would do this at the Account level. Use EXISTS SQL clause for the Account filter on the children.
  • Objects that are not to be cloned should be left out of the conversion schema.
  • Objects that are to go with all their children will be marked with an ‘R’ in their DELETE_FLAG so all their children will be auto selected for the initial upload.
  • Objects that will not have all their children will be marked with an ‘I’ in their DELETE_FLAG and all their children will have to be selectively marked with an ‘I’ in their DELETE_FLAG.
  • An ETL job is created and run that marks all records that are to be uploaded based on each objects criteria (‘R’ or ‘I’ depending on the child rule).

If conversion will continue after the “big bang”…

  • In preparation for the ongoing updates all tables will have a LEGACY_ID added on all tables which will be populated as 
    “UPDATE TABLENAME SET LEGACY_ID = ID” after the original download.
  • There will be a unique index on all these LEGACY_IDs to enhance performance.
  • After the initial upload completes, ETL any changes from the operational schema to the conversion schema using SystemModStamp as a date filter.
  • LEGACY_ID will be used in the WHERE clause of the ETL inserts and updates to the conversion schema, since the ID’s have changed.
  • Use the rigorous list of all relationships to generate the foreign key required sub selects required to handle foreign key ID mappings.
  • If into a partially populated org, generate the required maps and mapping functions.
  • Truly incremental loading can happen frequently after the initial load, as often as necessary depending on the number of changes.

Salesforce Org Split

One organization splits into two, with each receiving only part of the data.

Exactly the same as the Clone procedure, except that…

  • Only certain records will be tagged as ‘R’, ‘I’ or ‘U’ for recover, insert, or update to the second org, depending on user-provided criteria.
  • Typical criteria will be at the Account level, so update queries can filter using EXISTS clause, doing lookups of the Account information for child records.

When completed, the second org’s records can be removed from the source org by…

  • Setting DELETE_FLAG = ‘D’ on database records the source org should no longer have
  • Running “–set {objectName}” command on source org
  • Deleting an Account is recursive on all child objects, except for open Cases and Closed Opportunities.

Salesforce Org Merge

Merge two orgs into one with combined structure and data

Prepare the merged org for the data

  • Map the source org’s custom objects and fields from the retiring org to the target org, including lists of field values
  • Copy over packages, validation triggers, Apex code, etc.
  • Resolve conflicting business practices

Apply mappings

  • Run –getGlobal on both orgs into separate schemas
  • Run SQL scripts to determine what columns are different
  • Set up ETL jobs to migrate the data from source org to target org, setting DELETE_FLAG to ‘I’ (insert) for all new records
  • Run –checkGlobal to validate upload order
  • Run –setGlobal to load the target Salesforce org

Synching Two Salesforce Orgs

Merge two organizations merge into one with combined structure and data

Prepare the merged org for the data

  • Map the source org’s custom objects and fields from the retiring org to the target org, including lists of field values
  • Copy over packages, validation triggers, Apex code, etc.
  • Resolve conflicting business practices

Apply mappings

  • Run –getGlobal on both orgs into separate schemas
  • Run SQL scripts to determine what columns are different
  • Set up ETL jobs to migrate the data from source org to target org, setting DELETE_FLAG to ‘I’ (insert) for all new records
  • Run –checkGlobal to validate upload order
  • Run –setGlobal to load the target Salesforce org

Relational Junction Patented Technology

Scalability: Massive data transfer capability to meet windows

  • United States Patent 8,122,040 yields a major competitive advantage for Sesame Software’s Relational Junction replication and data warehouse offerings, which includes products for Salesforce®, NetSuite® and QuickBooks®. Among the vendors offering replication and integration tools, only Relational Junction effectively replicate massive amounts of data for integration and analysis with other corporate data and for data backup to meet regulatory compliance mandated in a variety of industries.
  • Multiple pending applications for multi-threaded bi-directional replication
  • Results: Typically four to ten times faster that other conventional methods

Automatic generation of cross-reference indexes

  • United States Patent 8,745,029 provides a method for generating indexes for downloading data. This is essential to performance of the database triggers referenced in patent 8,375,010, “Data replication of related records to SaaS Data Sources”, and also boosts performance of reports and other operations that join tables.
  • Results: High performance for relationship triggers. Efficient reporting using table joins.

Recovery of Parent-Child Relationships to maintain the structure of the data in both one-time and ongoing transfer situations

  • United States Patent 8,375,010 provides a way for Sesame Software’s Relational Junction™ replication offerings to create related records in Salesforce.com, NetSuite, and QuickBooks in one pass, keeping the child records pointing to the parents as new parents are created in the SaaS system. This technique allows a user of the system to create new parent-child records with temporary keys in the relationship fields. As the new parent records are created in the SaaS system during replication, the replication process is notified of the new key generated by the SaaS application. The replication process updates the local database with this key. Database triggers generated ahead of time are knowledgeable of the relationships in the data model, and look for related record with the old key, updating the key values where found.
  • Results: Able to clone an entire Salesforce org with all parent-child relationships intact

Patented technology and Salesforce solutions for any scenario