Knowledge Hub

Advice and answers from the Restaurantology Team

Once you’ve completed all three steps in the Unit Import: Setup & Permissions article, you’re ready to begin importing unit-level child records—referred to hereafter (interchangeably) as “units,” “stores,” or “locations”—to their corresponding parent Account.

The process for importing Salesforce store records consists of four steps:

  1. View Related Units
  2. Compare Available Units
  3. Assess & Select Desired Units
  4. Import Units & Validate Results

[01] View Related Units


Users seeking to view units related to a multi-unit Concept can leverage the Restaurantology Insights Visualforce component to view units directly within Salesforce provided they are on a record that has previously been mapped to a RestaurantologyLog.

💡Learn More: Matching Salesforce Accounts to RestaurantologyLogs →

Clicking the “View Units” button will refresh the page and provide users with a pop-up containing matched store-level records. Note that no data is being downloaded to your instance during this step.

Having trouble getting started? Unit data visualization starts by clicking the View Units button in Restaurantology’s Account-level Visualforce component. Be sure R0_AccountBox has been added to your page layout, and make sure you have appropriate access and privileges to proceed.

‘View Units’ button available in Restaurantology’s Account Visualforce Component

[02] Compare Available Units


Before importing child records, users must perform a mandatory intermediate action required to compare the related Restaurantology units with existing Account records to assess which may be duplicates.

Stuck? If the “Compare and import” button is missing in the “View Units” pop-up, users likely lack the necessary permissions to perform the record import. We recommend you review the Restaurantology import permission settings in the Restaurantology App or contact your system admin.

Performing a comparison between existing and proposed units requires Restaurantology to first create a localized cache of all relevant records. This means you are downloading a version of these units into a custom object managed by Restaurantology, however no new Account records are being created in the process. Once the cache is created, Restaurantology then performs a deduplication process using Salesforce’s standard deduplicate tool and stores the results in the cache for later review and instructions. Users seeking to modify default Salesforce duplication behavior should consult their Salesforce administrator or refer to the platform’s documentation for guidance on customization options.

Salesforce Unit Import List View

[03] Assess & Select Desired Units


With the comparison (cache and dedupe) process complete, users are shown the results of the process and are ready to review which units they’d like to import. Any records Salesforce believes to be duplicates are flagged and subsequently prohibited from import. Users can take any actions they deem necessary to influence these results, such as:

  • Updating Account record names
  • Updating incomplete or incorrect Billing addresses
  • Updating existing SFDC duplicate rules for fields, tolerance, etc.

Each time you use the “Compare and import” button a new, refreshed cache is created and, thus, the results and any potential collisions will be reassessed.

Restaurantology Unit import includes standard Salesforce deduplication rules

[04] Import Units & Validate Results


Once you’ve decided which record(s) to import, you can complete the process by clicking “Import Selected Units.” Records will be inserted into your instance according to the standard and custom unit-level data enrichment mappings configured in step 3 of the previous setup article.

Important: Restaurantology unit imports employ Salesforce’s insert Account record method, rather than create, which exempts us from any field validation that might prevent record creation. However, any organization-specific workflow automation such as Flows, Process Builders, or Apex Triggers (managed locally or through additional managed packages), could lead to process failure if subsequent attempts to edit the newly-created record necessitate updates to specific fields.

Units imported via Restaurantology become child records with unique names