From Sunil Nandipati: Deploying Salesforce Scheduler from Sandbox to Production Environments
Preface
Customers who have streamlined development processes typically use multiple non-production environments (one for each probably – development, QA, integration, data migration, SIT and UAT). And it is a general practice that development teams develop in development sandboxes or scratch orgs first, check in their code to a repository and add instructions to deployment trackers – for deployment teams to perform the deployment steps. These can include any manual steps – related to enabling features, adding data etc. Typically anything that cannot be done using the metadata API.
Context
It is NOT a good practice to expect the deployment teams to repeat these steps manually in every single Org. Reasons can be many. To quote a few – prone to human errors while executing manual steps, time consuming, too much detailed documentation will be required and some customers do NOT prefer a partner or consultant to have administrator access to environments other than development.
Guidelines while deploying Scheduler
While deploying Salesforce scheduler between environments – consider categorizing your components into the following areas
Pre deployment activities
Include steps that need to be performed before migrating the codebase using the Metadata API. Ensure the system administrator has the Scheduler Permission Set license assigned first, then consider any manual steps of the features that are NOT yet supported by the MetaData API (or) any dependent packages that are required for your implementation.
Deploy code using Metadata API
Step 1 – Include feature settings that are related to “Salesforce Scheduler Settings” which need to be either Enabled or Disabled, should be covered first. Refer the Industries settings here – https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_industriessettings.htm
Note: The settings mentioned in Italic and which do NOT have a Metadata Reference are currently NOT supported by Metadata API – will be addressed in future releases (Safe harbor). If you are using these features – activate them manually as part of your pre-deployment steps
| Salesforce Scheduler Settings | Metadata Reference |
| Event Management | enableEventManagementOrgPref |
| Block Resource Availability | enableBlockResourceAvailabilityOrgPref |
| Multi Attendee Event | enableCreateMultiAttendeeEventOrgPref |
| Appointment Distribution | appointmentDistributionOrgPref |
| Aggregate Resource Use | captureResourceUtilizationOrgPref |
| Publish Appointments as Platform Events | enableEventWriteOrgPref |
| Multi Resource Scheduling | enableMultiResourceOrgPref |
| Concurrent Scheduling | enableOverbookingOrgPref |
| Operating Hours for Service Territory Members for Work Type Groups | enableTopicTimeSlot |
| Salesforce Scheduler for Health Cloud | |
| Resource Appointment Sharing | enableShareSaWithArOrgPref |
| Multiple Topics For Shifts | enableMultipleTopicsForShiftsOrgPref |
| Schedule Appointments Using Engagement Channels | enableAppFrmAnywhereOrgPref |
| Main Service Resource | enableAnyResourceTypeOrgPref |
| Drop In Appointments | enableDropInAppointmentsOrgPref |
| Drop In Skill and Skill Level Matching | enableDropInSkillMatchingOrgPref |
| Resource Availability Sharing Using Actionable List | enableActionableListOrgPref |
Step 2 – Include any customizations done to the product offering should be added to the Codebase (repository). Consider evaluating your customizations around
- Sharing settings – OWD and Sharing rules (include groups or roles – if sharing rules are around those)
- Custom fields on Scheduler objects
- New Picklist values on Scheduler objects
- Custom buttons, actions and links
- Changes to page layouts
- Flows
- Custom components that are added to the flows
- Custom classes and triggers
- Validation Rules
- Experience Cloud
- Lightning Out for Guest user on a customer website (endpoint URLs will be different)
Post deployment activities
Include steps that need to be performed for the scheduler solution to work. This will mostly include migrating your data and setting up the users and adding scheduler PSLs. Consider leveraging data loader or an ETL tool for data migrations and ensure data integrity (order of loads) and references are maintained post migration between the records in multiple objects.
- Objects
- Scheduler objects mentioned in ERD – https://help.salesforce.com/s/articleView?id=sf.ls_data_model_diagram.htm&type=5
- Plan a load sequence order. A sample load sequence would look like this. Evaluate your customizations to make sure this order applies to your implementation as well
| Salesforce Foundation Objects | |||
| SObjectName | Load Sequence | Relationships to Establish | |
| Profile | 1 | ||
| UserRole | 1 | ||
| PermissionSet | 1 | ||
| PermissionSetGroup | 2 | PermissionSet | |
| User | 2 | Profile, UserRole | |
| Product | 1 | ||
| PermissionSetAssignment | 3 | PermissionSet Or PermissionSetGroup, User | |
| Salesforce Scheduler CORE Objects | |||
| SObjectName | Load Sequence | Relationships to Establish | |
| Skill | 1 | Can also be migrated as Metadata (But recommendation is to do it as data migration) | |
| Skill Requirement | 2 | Skill | |
| Holiday | 1 | ||
| Operating Hours | 1 | ||
| Operating Hours Holiday | 2 | ||
| Work Type Group | 1 | ||
| Service Territory | 2 | Operating Hours | |
| Work Type | 2 | Operating Hours | |
| Work Type Group Member | 3 | Work Type Group, Work Type | |
| Service Territory Work Type | 3 | Service Territory, Work Type | |
| Service Resource | 3 | User | If using Assets as Service Resource, the order should be after Assets |
| Service Resource Skill | 4 | Service Resource, Skill | |
| Time Slot | 4 | Operating Hours, Work Type Group | |
| Service Territory Member | 4 | Operating Hours, Service Territory, Service Resource | |
| Appointment Assignment Policy | 1 | ||
| Appointment Scheduling Policy | 2 | Appointment Assignment Policy | |
| Appointment Topic Time Slot | 5 | Work Type Group, Work Type, Time Slot | |
| Salesforce CORE Transactional Objects | |||
| SObjectName | Load Sequence | Relationships to Establish | |
| Account | 3 | User | Owner of the Account Parent Account Id should be an additional Step if you manage hierarchy of Accounts And probably any custom look-ups if you have included Custom Fields |
| Contact | 4 | Account, User | |
| Opportunity | 5 | Account, Contact, User | |
| Lead | 6 | Account, Contact, Opportunity, User | When migrating Converted Leads |
| Asset | 5 | Product, Account, Contact | |
| Salesforce Scheduler Transactional Objects | |||
| SObjectName | Load Sequence | Relationships to Establish | |
| Resource Absence | 4 | Service Resource | |
| Resource Preference | 6 | Service Resource, Related (Account, Lead OR Opportunity) | |
| Shift | 6 | Service Resource, Work Type, Appointment Topic TimeSlot | |
| Service Appointment | 7 | Service Territory, WorkType, Account, Parent Record (Either Account, Lead OR Opportunity) | |
| Assigned Resource | 8 | Service Resource, Service Appointment | |
| Event | 9 | Service Appointment, WhatId (Asset, Account OR Opportunity), Owner (Users), WhoID (Lead OR Contact) | |
| Appointment Invitation | 8 | Work Type OR Work Type Group, Service Territory | |
| Appointment Invitee | 9 | Appointment Invitation, Service Resource |
Note – even the scheduling policies and assignment policies have objects (AppointmentSchedulingPolicy and AppointmentAssignmentPolicy) – they can be migrated.
Few best practices to keep in mind
- Consider deactivating picklist values that come OOTB if there is NO plan to use them in your solution
- If you have hardcoded any IDs in your flows (for defaulting any records like Work Type Group, service territory etc.) – replace with Production IDs wherever appropriate
- Turn OFF Rules (Validation, Escalation, Assignment, Workflows, Process builders, Flows, Sharing Rules) to avoid getting errors while performing data loads
- Re-calculate Sharing Rules post migration of all data
- And Finally explore sfdx-cli data tree import option to load in fewer amount to steps
- Make sure the number of records getting loaded are fewer than 200 in a single step (thats the limitation to look for when using the data tree import option with sfdx-cli)
- Refer here – https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm#cli_reference_force_data_tree_import
References
- https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_industriessettings.htm
- https://developer.salesforce.com/docs/atlas.en-us.salesforce_scheduler_developer_guide.meta/salesforce_scheduler_developer_guide/salesforce_scheduler_data_model.htm
- https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm#cli_reference_force_data_tree_import