Name a scenario where the administrator will defer sharing calculation permissions?
When an admin needs to perform a large number of configuration changes which could lead to very long sharing rule evaluations or timeouts.
The deferral can help users process a large number of sharing-related configuration changes quickly during working hours, and then let the recalculation process run overnight between business days or over a weekend
What is the best practice when you want to use the most efficient operations when loading data from the API?
Use the fastest operation possible - insert() is fastest, update() is next and upsert() is next after that
Ensure the data is clean before loading when using the Bulk API. Errors in batches trigger single-row processing for that batch, and that processing heavily impacts performance.
What is an option when you want to reduce the data to transfer and process when loading data from the API?
Send only the fields that have changed (delta-only loads)
What is the best practice when you want to reduce transmission time and interruptions when loading data from the API?
For custom integrations:
- Authenticate once per load, not on each record
- Use GZIP compression and HTTP keep-alive to avoid drops during lengthy save operations
What is the best practice when you want to avoid unnecessary overhead when loading data from the API?
For custom integrations, authenticate once per load, not on each record.
What is the best practice when you want to avoid computations when loading data from the API?
Use Public Read/Write security during initial load to avoid sharing calculation overhead
What are the possible steps to take when you want to reduce computations when doing initial loads from the API?
If possible for initial loads, populate roles before populating sharing rules
- Load users into roles
- Load record data with owners, triggering calculations in the role hierarchy
- Configure public groups and queues, and let those computations propagate
- Add sharing rules one at a time, letting computations for each rule finish before adding the next one
If possible, add people and data before creating and assigning groups and queues
- Load the new users and new record data
- Optionally, load new public groups and queues,
- Add sharing rules one at a time, letting computations for each rule finish before adding the next one
What is the best practice when you want to defer computations and speed up load throughput when loading data from the API?
Disable Apex triggers, worfklow rules, and validations during loads; Investigate the use of bach Apex to process records after the load is complete
What is the best practice when you want to Balance efficient batch sizes against potential timeouts when loading data using SOAP API?
When using the SOAP API, use as many batches as possible - up to 200 - that still avoid network timeouts if:
- Records are large
- Save operations entail a lot of processing that cannot be deferred
What is the best practice when you want to optimize the Lightning Platform to work with Salesforce when loading data from the API?
Use Lightning Platform Web Service Connector (WSC) instead of other Java API clients, like Axis
What is the best practice when you want to minimize parent record-locking conflicts when loading data from the API?
When changing child records, group them by parent -
ex: group records by the field ParentId in the same batch to minimize locking conflicts
What is the best practice when you want to defer sharing calculations when loading data from the API?
Use the defer sharing calculation permission to defer sharing calculations until after all data has been loaded
What is the best practice when you want to avoid loading data into Salesforce?
Use mashups to create coupled integrations of applications
What is the best practice when you want to use the most efficient operations when extracting data from the API?
Use the getUpdated () and getDeleted() SOAP API to sync an external system with Salesforce at intervals greater than 5 minutes.
Use the outbound messaging feature for more frequent syncing
When using a query that can return more than one million results, consider using the query capabiity of the Bulk API, which might be more suitable
Name 5 possible best practices you can take when you want to upload data (that will make your life easier in terms of locking, calculation time, etc)
- Disable triggers (or have bypass logic for triggers), workflow rules, validation rules (but not at the cost of data integrity)
- Defer calculation of sharing rules
- Insert + Update is faster than upsert
- Group and sequence data to avoid parent record locking
- Tune the bath size (HTTP Keepalives, GZIP compression)
- Minimize the number of fields loaded for each record. Foreign key, lookup relationships, and roll up summary fields are likely to increase processing times.
- Minimize the number of triggers where possible, or alternatively, convert complex trigger code to Batch Apex that processes asynchronously after data is loaded
What is the impact of organization -wide sharing defaults when loading data?
When you load data with a private sharing model, the system calculates sharing as the records are being added. If you load with a public read/write sharing model you can defer this processing until after cut over
What is the impact of complex object relationships when loading data?
The more lookups you have defined on an object, the more checks the system had to perform during data loading. If you can establish some of these relationships in a later phase, loading will be quicker
What is the impact of the following two sharing rules (ownership-based vs criteria based) when loading data?
If you have ownership-based sharing rules configured before loading data, the insert requires sharing calculations if the owner belongs to a role or group that defines the data to be shared.
If you have criteria-based sharing rules configured before loading data, each record with fields that match the criteria also requires sharing calculations
What is the impact of workflow rules, validation rules, and triggers when loading data?
They can slow down processing if they are enabled during massive data loads
When loading lean, what are the 3 things you should load first?
- Parent records with master-detail children (Parent record has to exist before loading child records)
- Record owners (users): Owners need to exist in the system before you can load the data
- Role Hierarchy: No benefit to deferring setting up the role hierarchy in the beginning (versus at the end)
When you turn off validation rules, workflow rules, assignment rules and triggers, what can you do to preserve data integrity prior to the data loads?
Before loading the data
- Query data set before loading to find and fix records that don’t conform to the rules
- Extract parent IDs and update the source data to include the parent IDs before loading the child records
When loading data and you don’t want triggers to fire off, what can you do?
Create a custom setting and corresponding checkbox to control when a trigger should fire. Then include that statement in your code to check for these.
If you had turned off validation rules, workflow rules, assignment rules and triggers, what are 4 possible steps you should do after you loaded the data (and before turning the rules back on)
- Add lookup relationships between objects, roll-up summary fields to parent records and other data relationships between records
- Enhance records in SFDC with foreign keys or other data to facilitate integration with your other systems.
- Batch Apex and Bulk API are efficient methods for performing these udpates to a large number of records
- Reset the fields on the custom settings you created for triggers
- Turn validation, workflow and assignment rules back on
What are the 4 sequenced steps for loading data?
- Configure org for the data load
- Prepare to load data
- Execute the data load
- Configure org for production
