20 July 2016

Project Overview - Email to Case rollout


Set Up Customer Support






business hours



holidays







queues









Created a new Role - Validation Team

To make it easier to add reps to the queue I'm splitting up the support team as they actually are.  Half are support reps.  Half are Validation reps.  
Updated Sharing setting to account for this role. 
Edit | Del Owner in Role, Internal and Portal Subordinates: Director of Global Sales Role: NA Customer Support Rep Read/Write Read Only Private Read/Write
Edit | Del Owner in Role and Internal Subordinates: Director of Support Role: NA Customer Support Rep Read/Write Read/Write Private Read Only


assignment rules


escalation rules




Support Settings

  1. Changed default case owner from Janette Houser to Jennifer Welty
  2. Enable Feed Tracking
    1. Page Layout for Feed-Based Cases
      1. didn't match a few items
        1. Send Email Button
        2. On-Demand Email (yet)
  3. review settings
  4. Updated all of the list views so only the queue members can see the cases in the queue 
  5. Customizing the 'Custom Console Components' in the page layout.
  6. Re-Open a closed case when an email is received
    1. Why can't I create a new email trigger in production?!    
      1. Answer: 
      2. You cannot create or edit Apex classes or triggers in a production organization (unless it's a free trial).    To use Apex classes or triggers in a production organization, you need to write them in a Sandbox or free Developer Edition organization--along with the required automated tests to meet or exceed code coverage requirements--and then use one of our deployment tools (the Force.com IDE or the Force.com Migration Tool for Ant) to push your classes and triggers to production.   The reason for this is that all Apex code must be covered by automated tests in order to be deployed to production.   If you tried to write a trigger in production, you wouldn't have a test so it wouldn't save.   If you tried to write the test first, the test would fail because your trigger wasn't working, so you couldn't save that either.  So instead, you do all of your development work in a non-production organization, where these rules are not enforced, and then you can deploy your code and tests to your production organization to make their functionality available to end users.
      3. While validating the inbound change set it errors out.  I'm posting to the community.  
        1. That's pretty incredible.  Stephanie Dodson basically walked me through the whole change set deployment.   I needed to:
        2. turn off the validation rule for first name on contact records
        3. create an apex class to test the apex trigger then run it in the dev. console
        4. add both the class the trigger to the outbound change set in the sandbox. 
        5. inbound validate and deploy to production
  7. Notify Reps when customer responds to case. - created the two workflow rules in production
    1. mark New Email field when customer email
    2. unmark New Email when rep replies
  8. Set One 'From' address for reps to choose from.
  9. Omni-Channel
  10. Set up email templates such that the customer support signature, subject line and email body are defaulted.
    1. created the default email template and 3 templates i've received so far. 
  11. Service Cloud
    1. Enable On-Demand E2C
    2. Define and Verify Routing Addresses
      1. Created global action to Send Email and make it part of the feed on the Case page.
  12. Email address from Case not updating the Contact record. Here's the fix. - can't create this until email-to-case is enabled
*Bold font mean complete in production org.

No comments:

Post a Comment