#Customer Service12 debatiendo

Hi Vadim,

Case Assignment Rules don't natively understand an employee's work schedule or whether a user is currently working.

A common approach is to maintain a simple Support Availability/Schedule object or fields that indicate whether a support analyst is available for assignment. Your assignment logic can then check that availability before assigning the Case.

If you're using a custom assignment process, Apex can query the available analysts and assign the Case accordingly. You could also maintain separate queues for different shifts and route Cases to the appropriate queue rather than directly to individual users.

For a small support team, queues plus a simple availability mechanism are usually easier to maintain than building a full scheduling system. 

Hi Justin,

Your use case can fit well with Cases + Service Contracts + Entitlements, without necessarily requiring a very complex implementation. 

I would consider using the Case as the customer/service issue and the Service Contract/Entitlement to determine what coverage and response expectations apply. Your custom Work Order can then handle the field-service-specific details such as dispatch, technician, diagnosis, parts, and trip/debrief information. 

For the warranty scenario, you could create separate entitlement rules for manufacturer warranty vs. customer service contracts, and have the Case determine which entitlement applies. You can then track metrics such as response time, number of trips, and resolution time to identify where repeat visits are occurring. 

I would start with the standard Case/Entitlement functionality and keep the Work Order integration as simple as possible, adding automation only where it removes manual steps. 

Hi Willow,

Rather than using the Case Last Modified Date, you can track the inbound emails associated with the Case. With Email-to-Case, each incoming email can be associated with the existing Case, so the email records can be used to count how many inbound messages were received. 

You could then create a report grouped by Case and count the inbound emails to measure the actual volume of customer responses/questions, even when they all belong to the same Case. 

If you need that count stored directly on the Case, you could use automation/custom Apex to maintain an "Inbound Email Count" field whenever a new inbound email is received. 

This would give you a much more accurate measure of the CS workload than simply counting Open Cases. 

Hi Sandra,

Not receiving the installation confirmation email is a common hiccup in Salesforce, but as long as the package installation screen showed complete without throwing critical errors, the package is almost certainly installed in your org. You don't actually need that email to proceed.

Here is how you can verify and fix both issues:

1.Check Installed Packages:Package Verification. 

Go to Setup > Installed Packages to confirm whether "Groundwire Volunteers for Salesforce" (or Volunteers for Salesforce) appears in your list with a valid version number. You can verify success when the package name and components are visible in the package list.

2.Check Session Settings or Domain:Help Link Redirect Fix. 

The help link redirect issue usually happens due to browser cookie conflicts or missing domain/session security settings that invalidate your session token when jumping to external domains. Try clearing your browser cache, logging out and back in, or checking your Session Settings in Setup (such as "Lock sessions to the IP address from which they originated"). You can verify success when clicking help links opens the documentation page without throwing access errors.

Hi Demps,

The message about the “inforce connector” suggests that the Request Update feature is using a third-party LinkedIn integration rather than a standard Salesforce feature. The “solution provider” would therefore be the vendor that supplied that connector/integration. 

Since this is from 2012, the LinkedIn integration/API may no longer be supported, which would explain why the login/authorization step is failing. The Salesforce Community post itself does not identify the provider or provide a current fix. 

I would check Setup → Installed Packages and Connected Apps for the Inforce/LinkedIn integration and identify the package/vendor. If the package is no longer supported, the Request Update feature would need to be replaced or updated with a supported LinkedIn integration. 

If you can provide the Inforce package name/version o

Hi,

For duplicate Ideas, there isn't a standard user action to merge two Idea records yourself. If you identify duplicates, you can flag/report them to the IdeaExchange/Product Manager team so they can review and determine whether they should be merged or otherwise handled. 

I'd recommend including the links/IDs of the suspected duplicate Ideas and explaining why they're duplicates. Avoid simply assuming that similar titles should be merged, since the Ideas may have different use cases or requirements. 

For the “Idea bundle/lot” review date, that isn't generally exposed as a standard field on the Idea. If you need to know when a Product Manager last reviewed a particular group of Ideas, that would depend on whatever internal process Salesforce uses for managing those Ideas.

Hi Har par,

For this requirement, you should use Email-to-Case along with Web-to-Case. Web-to-Case creates the Case from the web form, but it doesn't automatically capture subsequent customer email replies. 

With Email-to-Case configured, customers can reply to the Case email and Salesforce can associate the incoming email with the existing Case, so the message is recorded in the Case's activity/history instead of relying on users' Outlook inboxes. 

You can also configure your Case assignment rules/queues so the Cases are routed to the appropriate queue based on the brand/type. 

If inbound emails still aren't being attached to the Case after enabling Email-to-Case, check the Email-to-Case routing address and the Case email threading settings.

Certain Profiles like the Chatter Free User can be assigned Record Types which cannot be removed by clicking an edit link in the Record Type Section of the Profile. This prevents Record Types from being deleted. In order to remove the record type from the Profile a URL 'Hack' must be performed.

First, the Enable Enhanced Profile User Interface checkbox in the User Interface must be deselected:

Setup> Customize> User Interface> Setup Section> Deselect  Enable Enhanced Profile User Interface> Save

Proceed with the following Steps:

1)Please follow this click path:

Setup> Manage Users> Profiles> System Administrator> Navigate to Record Types> Click the Edit Link on the Object in question's Section

At this Point you will be at the Edit Record Type Settings Page for the Object.

2)Copy the URL from the adress bar on your browser and paste it into note pad:

3)Now follow this click path

Setup> Manage Users> Profiles> Chatter Free User

4)Copy the 15 digit Salesforce Id from the URL in the Adress bar of your Browser:

yyyyyyyyyyyyyyy

5)You are now going to replace the id in the Edit Record Type Settings Opportunity Page ( the first id number right after the "jsp?id=" in the URL ) with the Id from the Chatter Free User.

This:

Should now look like this:

xxxxxxxxxxxxxxx was replaced with yyyyyyyyyyyyyyy

6)Now take the modified Url and place it in the Adress bar of your browser and hit enter.

*************This will seem to have taken you to the System Administrator's edit page but you are in the right place.******************

7)You will now be able to remove the value by highlighting it and selecting remove. Switch the Default record type to whatever you like and hit save.

All you need to do now is repeat this for any other Profiles in which it is necessary, then Deactivate and Delete the Record Type.

Hi Allen,

The most common issue with values like Extreme / High / Moderate / Low is that they are subjective—what an agent considers "Moderate," an agitated customer might call "Extreme."

In ITIL and customer support operations, the gold standard is to tie Impact directly to scope and scale (who/what is affected), while leaving Urgency to handle time-sensitivity, and Severity/Priority to be the calculated outcome of both.

Recommended Best Practice Picklist Values for Impact

Instead of abstract adjectives, define Impact by the blast radius:

• Organization-Wide (or All Users): Critical infrastructure or service is down for every user; company-wide halt.

• Multiple Users / Department: A whole team, branch, or customer segment cannot perform critical work.

• Single User / Individual: Only one person is blocked, or the issue is localized to an individual machine/account.

• Minor / Informational: No operational disruption; cosmetic glitch, typo, or general inquiry.

The Standard Matrix Formula (Impact + Urgency = Priority)

When you define Impact by scope, you can automate your Case Priority (or Severity) using a formula or Flow matrix:

Key Operational Tips

• Use Field Help Text: Add clear definitions right under the field (e.g., "Select based on the number of users or business functions blocked").

• Don't let agents guess Priority: Let the agents evaluate the objective facts (Impact = How many people? Urgency = Is there a workaround / deadline?), and let the system calculate the SLA/Priority automatically. This removes emotional bias from case triage.