Set One 'From' address for reps to choose from.

Set One 'From' address for reps to choose from. 

Added Org Wide email address for the customer support email.  Verified the address

all this did was add another From address to the drop list to choose from.  

Trying to remove the personal email option to email from. 

Will this work?   Asking Mike if he can help. 

In lieu of code I've set up a validation rule instead. 

Validation Rule Detail

Rule Name	from_address_is_support_email_only	Active
Error Condition Formula	NOT(FromAddress = "supporttest@company.com")
Error Message	'From' Email Address must be Support...	Error Location	Top of Page
Description	from address is support email only
Created By		Modified By

Updated: 

OR (NOT(Incoming),(FromAddress = "supporttest@confirmation.com"))

7/20/2016 update

added filter that this only triggers the validation for the customer support role reps. 

AND 
(OR 
($UserRole.Id = "00E12000000Wu22", $UserRole.Id = "00E120000012x39", $UserRole.Id = "00EA0000000aY19", $UserRole.Id = "00E12000000FPvB") 
,(OR (NOT(Incoming),(FromAddress = "supporttest@confirmation.com") 
) 
) 
)

Setting this up for APAC too. 

AND 

(OR 

( $User.ProfileId  = "00e12000000bWKh",  $User.ProfileId  = "00e12000000fJ2B",  $User.ProfileId  = "00e12000000fJ2u") 

,(OR (NOT(Incoming),(FromAddress = "supporttest@confirmation.com") 

) 

) 

)

Notify Reps when customer responds to case.

Notify Reps when customer responds to case. 

Building this so that when emails come in from the customer reps can see a notification of that in a list view.
_____

Hi,

There is a workaround,  First you need to create a custom field or flag (Checkbox) on Case, The use workflow to update the field whenever a new email arrives,  Use this steps

To create the workflow rule that updates a case field on an inbound email:

• Go to Setup | App Setup | Create | Workflow & Approvals | Workflow Rules and click New Rule.  
• Select Email Message as the Object the workflow rule applies to and click Next (note that Email Message will only be available if email-to-case has been enabled in the org). 
• Enter a name for the workflow rule and select when it should be evaluated.
• Enter the following criteria to enable the workflow rule to fire when an email is inbound:
• 'Email Message: Is Incoming' equals 'True'
• Add additional criteria if you only want the workflow rule evaluated under certain circumstances such as Case: Closed equals True, or Case: Status does not contain Closed.
• Click Save & Next
• Click Add Workflow Action and select New Field Update
• Enter a name for the Field Update and then select the case field to update.

 Then, You Can Create a list view based on Filter value using that custom field.

Note:- You have to update that field again via using Workflow once any step taken on the email.

Hope this helps,

--
Thanks,
Swayam
_____

Need to remove the New Email checkbox check after the case is replied to.
Done:

Re-Open a closed case when an email is received

Knowledge Article Number	000220076
Description	Sometimes a case is closed, and then the customer replies with new information or a new issue. The email gets attached to the original case, however, since the case is closed, there's no notification that the customer is waiting on a response. We'll show you how you can use a simple workflow rule/field update to reopen such cases.
Resolution	Go to Setup. Under "App Setup" or "Build" click Create | Workflow & Approvals | then Workflow Rules.  Click New Rule.  Select Email Message as the Object the workflow rule applies to. Click Next.  Enter a name for the workflow rule and select when it should be evaluated.  Enter the following criteria to enable the workflow rule to fire when an email is inbound and the case is closed:  Email Message: Is Incoming' equals 'True. Case: Closed equals True. Please note that you can add more to the rule, but these are the only steps truly required         5. Click Save & Next.         6. Click Add Workflow Action.         7. Enter a name for the Field Update and then set the Status case field to update.         8. Select the value you would like the re-opened case to be set to, and then Save (please note, you might want to add a new Case Status value for "Case Reopened", to signify when one is reopened via email - you'll need to have that value created before you can select it.)                       9. Activate the rule, and you should be able to make it working.

Putting this in now. 
Added the Case REOPENED item too.  Needed to update list views to add reopened cases to them. 

This gets me half-way there. 
If the customer emails back to an open or closed case we want the case to go back through the Assignment rules. (in case rep is out of the office or something)

came across this
I'll admit.  I have no idea what this code means but I've created an email Trigger (setup - email - triggers) and pasted the code in there. 
Posting the trigger here just to get it out there. 

trigger EmailMessage on EmailMessage (after insert) {
    List<Case> casesToAssign = new List<Case>();
    AssignmentRule ar = [SELECT Id FROM AssignmentRule WHERE SObjectType = 'Case' AND Active = true LIMIT 1];
    Database.DMLOptions dmlOpts = new Database.DMLOptions();
    dmlOpts.AssignmentRuleHeader.AssignmentRuleId = ar.Id;
    for(EmailMessage e : Trigger.new) {
        if(e.Incoming) {
            Case c = new Case(Id = e.ParentId);
            c.setOptions(dmlOpts);
            casesToAssign.add(c);
        }
    }
    update casesToAssign;
}

Created by frontendloader

When I was speaking with one of the support reps a few months ago, they were showing me what they did with emails from customers.  The rep who was going to handle a particular email notified the rest of the team that she was taking that email.   So, in order to eliminate this ambiguous case assignment I'm enabling Omni-Channel routing with the ability to push cases to reps.

Email address from Case not updating the Contact record. Here's the fix.

Email address from Case not updating the Contact record.   Here's the fix. 

Create a Process

 This will allow the case's email address to populate the associated contact's email address IF that contact's email address is not already populated. 

Have Cases Sent Back Into the Appropriate Queue if Customer Replies

Have Cases Sent Back Into the Appropriate Queue if Customer Replies

Our support team wants customer email responses associated with open or closed cases to go back into the Support Queue they were assigned to. 

Using the New Email field I created earlier I'm creating a Process that assigns Cases to queues based on the Account's region, Account Type AND when New Email IS CHANGED and IS TRUE. 

Working so far...

Issue: Some cases are closed and not associated with an account OR the account doesn't have a region assigned.  This flow will break.

Step by Step Through Email-to-Case, again, again

Guide I'm following now that I've got a test email address from the IT that's actually set up on our Exchange Server and not just a gmail account. 

following the guide...

Service Cloud Workbook  

Logging in to my Partial Copy Sandbox.   The same sandbox I'm setting up for Service Console, refreshed from the last update.  
Turn on On-Demand Email-to-Case.   I believe this is the one we're going to go with so testing this first.  

Differences between Email-to-Case and On-Demand Email-to-Case.

Second sentence of step 1...  Note that this step assumes you’ve set the Default Case Owner and Automated Case Owner in Salesforce—these settings just make sure that each case is automatically assigned an owner and not lost in a technological void. 

Didn't do that yet!  Heading there now. 

Going through the Support Settings...  
    | Setup | Support Settings

Customize Support Settings  
Here's a breakdown of what each of the setting entail. 

Now I've come across a comment regarding assigning a queue as the default case owner.  I don't have any queues yet so back tracking again. 

OK, starting here instead...

Setting up Salesforce to Salesforce Connection

We have a reseller of our product based out of South Africa.   While I have worked on an existing SF2SF connection I have yet to set up one from scratch.  Here we go...

So right off the bat I found this site on the developer forums.  Perfect for this initial setup.  I'm familiar with the Connections tab, available after you Enable Salesforce to Salesforce from the setup menu, but I didn't know the Connection would be with a Contact that exists in your org.  Make sure they have the right permissions to do this in their org.

Instead of grabbing screenshots from my org I'll just be pasting from the link above...

Enabling Salesforce to Salesforce

Before you can use Salesforce to Salesforce (S2S), you have to enable it. This has to be done by both parties - on your org, as well as on the org with which you are going to share data. Administrators can enable Salesforce to Salesforce by accessing it in the setup menu. Note that once the preference is enabled, it cannot be disabled.

To enable, navigate to Setup -> App setup -> Customize -> Salesforce to Salesforce -> Settings. Hit Edit, select Enable, and then select Save.

Once Salesforce to Salesforce is enabled in your org, you can establish data sharing relationship with another org by sending an invitation (we will cover sending invitations in a later section). You can customize the invitation by modifying the from email address, display name and email templates used for sending the invitation emails.

As a final step in this initial setup, you need to ensure that the user(s) managing the S2S connections have the appropriate permission to do so. In particular, enable the “Manage Connections” permission on the profile of the users. System administrator can create a new profile, for example "S2S Admin", and assign it to users who will be managing the connection. In smaller organizations the system administrator himself will probably be the person managing connections, in which case you may not need to create a separate profile.

You'll need to accept the connection via the email the contact will receive...

Setting up a Connection

Let's assume that your company, as well as another company, have enabled Salesforce to Salesforce. Even though both orgs have S2S enabled, you have to establish a formal relationship between the orgs before sharing can take place. This is done by setting up a connection.

For the sake of a running example let's use two companies

1. Acme Corp - this wil be the connection initiating company.
2. Appirio - this will be the connection receiving company.

As a best practice, in Acme Corp, create an account representing the company that will receive the connection (Appirio), and also create a contact with email address under that account. This contact will typically be used when sending the S2S connection invitation.

To begin using Salesforce to Salesforce, you need to use the Connections tab. If you don't have it in an application, add it by navigating to Setup -> My Personal Information-> Change my Display -> Customize My Tabs.

In new version we need to follow; Click on your name on right top corner -> My Settings -> Go to Display & Layout -> Customize My Tabs

On the Connections tab, click New to create a new connection with another org.

Select a contact under an account representing the other organization you want to share records with via S2S, and click "Save & Send Invite". The invitation email will be sent to the email address under the selected contact.

A connection owner also needs to be defined. The connection owner will receive all email notifications including system notifications in case there is a functional error when the connection is inserting/updating a record. Additionally, the connection owner will be assigned as the default owner of any new records, though this may be overridden by any assignment or other rules that determine record ownership.

When you click "Save & Send Invite" in this example, the Appirio system administrator (Joe Partner) will receive an email. Joe Partner will need to paste the URL in the browser address bar and login to initiate Salesforce to Salesforce connection. Here's an example invite:

Once logged in the Appirio org, the system administrator needs to hit Accept for the connection to start sharing records with Acme Corp.

Once the invitation is accepted, the connection to Acme Corp is established, no objects (standard or custom) are shared yet. Only data you choose to share will be shared - and that's that subject of the next section.

I'm Publishing Account information with our re-seller.  They're publishing Opportunity info.  Of course we're Subscribing to the respective Publications...

Publishing Objects

Once the connection is established, the next step is to publish and subscribe to objects. Both Acme and Appirio can publish and subscribe to each other's objects and fields.

To continue the tutorial, let's publish objects from Appirio. Do this by clicking on Publish in the Connection tab, and selecting the object that you wish to publish. You can publish most standard objects and all custom objects. We've selected Account, Attachment, Case, Case Comment, Contact and Lead.

Select Edit on an object to choose the fields that you wish to publish to the other environment.

As the following diagram indicates, we've chosen only to publish a handful of the fields related to an Account.

Modify each object to select the fields that you want to publish. This completes the publishing setup on the Appirio org. Let's now turn to the other environment and subscribe to these objects.

Subscribing to Published Objects

The receiving environment (Acme Org in our case) doesn't automatically have access to the data published from the Appirio environment. Rather, the org must first subscribe to the objects.

Login to Acme Corp and subscribe to these two objects and map the fields. This is done by navigating to the Connections tab, selecting the Appirio connection, and hitting "Subscribe". You'll now be presented with a list of the published objects to which you can subscribe:

The table essentially declares the mapping between the objects from the incoming org, and the objects to which they'll map in the receiving org.

An additional flag is sometimes displayed - Auto-Accept. If this option is selected, then records from the publishing org will be automatically accepted - the process will be entirely automatic. If you don't select the checkbox, then an administrator will first have to review incoming records before they are accepted. The checkbox is not always displayed. In particular, child objects are automatically accepted if parent objects are accepted, and the option is not available for junction objects either.

Now click Save. This completes the object level mapping. That is, we've defined which object from the Appirio environment maps to which object in the Acme environment.

Now you need to map the fields. Do this by clicking on Edit next to each object. Here we do so for the Account object.

Now map the published Account fields from the incoming environment to the the Account fields in your environment:

As the above diagram shows, we've mapped each field to the same field in the object in the receiving environment.

Field Mappings considerations

You may have come across situations where certain fields are not available for publishing, or where you are not able to subscribe to map some fields onto other fields. Here's a little more about this field mapping and how to resolve these.

• Data Type matching - Only matching data type fields can be mapped. In other words, the mapping enforces field type, dimension and precision. So for example, you can map a text field to any other text field of equal or greater size. Lookup or reference fields can be mapped to text fields (of size 80 or greater), and auto-number fields can also be mapped to text fields (of size 30 or greater).

• Field visibility - Lookup IDs are not available for publishing. You can enable S2S for those fields by creating a formula field and then publishing the formula field. In advanced section of formula field, select treat blank as blank.

The Salesforce to Salesforce setup is complete for Account and Contact objects sent from Appirio to Acme Corp. A similar setup can ensure that Account and Contact objects be shared from Acme Corp to Appirio.

Now for the details of sharing these records...

Using the Shared Connection

Now that you've got both environments set up on Salesforce to Salesforce, let's look at how the configuration can be used.

A one-way share between two environments is achieved by having the source environment publish, and the target environment subscribe. Here the source environment acts as a master environment and would overwrite shared records in the target environment whenever there is a change to the record in the source environment. Any changes made to the shared record in the target environment are lost when the source environment record changes in this scenario.

and this is critical to our situation...

A two-way share between environments is achieved by having both environments publish and subscribe to each others objects.  Now shared records between the two environment synchronize whenever there is a change on either side.

In both cases, the Salesforce to Salesforce mapping determines which fields would flow from one org to the other.

Records can be shared in two ways , either manually or programatically.

How to Share...

Manual Sharing Records

Account, Contacts and most standard and all custom objects can be shared externally using S2S, Go to List view for the object and Select the records and click on "Forward to connection".

Select the connection and related objects if there are any, and save.

Note that only users with the Manage Connections profile permission will see the "Forward to connection" option. Additionally, users can only forward records they own or those owned by their subordinates (role hierarchy). System admins can share any record.

When records are forwarded, records will be automatically created in the target environment if auto-accept for the object is enabled. If it's not enabled, the records sent will need to be explicitly accepted in the target environment as shown in screenshots below. In particular, in the target environment select the object (Account in this example) tab, click on the Go button in "Accounts from connections":

Then click on "Accept" to accept the record in the target org.