#SalesforceLive1 debatiendo

Hi Bobby,

Could you clarify which Work Queue and High Velocity Sales release/session you’re referring to? 

If you mean whether standard Salesforce Tasks can appear alongside cadence-generated tasks in the same Work Queue, the behavior depends on the specific HVS/Work Queue functionality available in that release. 

If you can share the Salesforce Live session or a screenshot of the Work Queue you’re referring to, we can confirm the expected behavior. 

Hi Nydia,

Could you clarify what you mean by a Round Robin method in Territory Planning and which Salesforce release/version you’re using? 

If you’re referring to automatically distributing accounts or leads evenly among territories or territory members, the available options can depend on the specific Territory Planning functionality and configuration. 

If you can share a little more about what you’re trying to assign and the expected round-robin behavior, we can provide a more specific answer. 

Hi Patrick,

That would be a useful enhancement for High Velocity Sales. Ideally, an automated out-of-office reply could be detected and the prospect's cadence temporarily paused, with the cadence automatically resuming after the specified number of days. 

For the current behavior, it would depend on what email/cadence functionality was supported in that release. If you’re still looking for this capability, could you share whether you’re using the standard High Velocity Sales cadence features or any custom automation? 

If the functionality isn’t currently supported, this would also be a good candidate for a Salesforce Idea/Product feedback. 

Hi Graciela,

A common use case would be to use an Incident to represent a service outage or broader issue, while Cases represent the individual customers/users reporting that issue. 

For example, if a service is unavailable, you could create one Incident and associate the related Cases with it. The support team can then track the overall incident s 

eparately while continuing to manage each customer's Case and communication.

A Problem can also be used when you need to investigate the underlying root cause of recurring incidents.

The exact relationships and automation available depend on the Incident Management features enabled in your org. 

Hi John,

Cases and Incidents serve different purposes in the IT Service Management model.

A Case is generally used to manage a customer or user support request, while an Incident represents an interruption or degradation of a service that needs to be restored. 

An Incident can therefore be used to coordinate the underlying service issue, while related Cases can represent the individual user/customer reports associated with that incident. Problems can then be used to investigate the underlying root cause when the issue is recurring. 

The exact relationship and available configuration depend on the IT Service Management/Incident Management features enabled in your org. 

Hi Meryl,

The overlap is mainly around IT service management and incident handling, but the two offerings have different scopes. 

Incident Management is focused on identifying, tracking, coordinating, and resolving incidents, including collaboration and communication during an incident. 

Salesforce IT Service Center is broader and is designed to support internal IT service operations, including service requests and other IT service-management processes. 

The best fit would depend on whether your primary requirement is incident response or a broader IT service-management workflow. If you can share the specific IT Service Center functionality you’re comparing, we can look at the differences in more detail. 

Hi Melanie,

If you’re referring to the Incident Management integration with Slack, the purpose is primarily to bring incident information, collaboration, and notifications into the relevant Slack channels. 

It doesn’t automatically mean that Salesforce Support is pulled into the Slack channel when the underlying incident is a Salesforce platform/support issue. Salesforce Support engagement would generally still follow the normal support case process. 

If you’re seeing a specific feature or release note that suggests otherwise, please share it and we can clarify the intended behavior. 

Hi Cindy,

The main difference is how the Lead is matched and assigned. 

Standard Lead Assignment uses Salesforce Lead Assignment Rules, typically matching criteria such as Lead fields and assigning the Lead to a specific user or queue. 

Maps Lead Assignment uses Salesforce Maps-based location information to determine assignment, which is useful when Leads need to be routed based on geographic location, territory, or proximity. 

So, if your assignment logic is primarily based on Lead field values, Standard Lead Assignment would generally be the approach. If geographic/territory information is an important part of the assignment, Maps Lead Assignment may be more appropriate. 

If you can share the specific Winter ’22 feature or configuration you're looking at, I can provide a more detailed comparison. 

Hi Alejandro, 

Could you share a little more detail about which Salesforce Field Service release or Salesforce Live session you’re referring to? 

For the Self-Service Scheduling and Work Plan custom actions questions, the exact release/version and feature context would help clarify whether these capabilities were available, changed, or had specific limitations at that time. 

If you can share the session or release notes you’re referring to, that would help narrow it down. 

Hi Irfan,

For HIPAA compliance, Salesforce security should be implemented as part of an overall compliance approach rather than relying on a single feature.

Some key areas to review are:

• Enable appropriate encryption for sensitive data, such as Salesforce Shield Platform Encryption where applicable.
• Use profiles and permission sets to enforce least-privilege access.
• Configure OWD, sharing rules, and role hierarchy carefully to restrict record access.
• Enable Field-Level Security for sensitive fields.
• Use Event Monitoring and Field Audit Trail where auditing and monitoring are required.
• Review integrations, APIs, external systems, and data exports to make sure protected health information (PHI) is handled securely.
• Establish appropriate retention, access, incident-response, and administrative policies.
• Confirm the required Salesforce contractual/compliance arrangements, such as a Business Associate Agreement (BAA), for the specific use case.

The exact design depends on what PHI you're storing, who needs access, and which Salesforce products/features you're using. 

If you can share your Salesforce edition, the type of PHI involved, and how users/integrations access the data, we can suggest a more specific approach