30 June 2016

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.  



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.
Enabling Salesforce to Salesforce

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.
Salesforce to Salesforce Setup
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.
S2s newconnection.png
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.
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.
S2s newinvite.png
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:
S2s sampleinvite.png
Once logged in the Appirio org, the system administrator needs to hit Accept for the connection to start sharing records with Acme Corp.
S2s accept.png
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.
S2s addremove.png
Select Edit on an object to choose the fields that you wish to publish to the other environment.
S2s editobject.png
As the following diagram indicates, we've chosen only to publish a handful of the fields related to an Account.
S2s fields.png
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:
S2s addsubscribe.png
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.
S2s map.png
Now map the published Account fields from the incoming environment to the the Account fields in your environment:
S2s editformap.png
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".
S2s forward.png
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.
S2s select connection.png
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":
S2s accountsfromcon.png
Then click on "Accept" to accept the record in the target org.
S2s acc.png



20 June 2016

Setting up Knowledge

As part of our roll out of Service Cloud and the Service Console we're setting up Knowledge in Salesforce.

Since there's a bit of a lull in waiting for the test email address from IT to get Email-to-Case going I decided to move ahead and work on setting up Knowledge now.

I have an email from marketing which will be my first knowledge article added.  First though, I need to work through the SET-UP GUIDE

Enable Salesforce Knowledge

I skipped straight to page 8 of the guide, enabling Knowledge...
To set up or edit your knowledge Base, from Setup, enter Knowledge Settings in the Quick Find box, select Knowledge Settings, then click Edit.




Currently I'm the only one adding and editing articles.  We bought 2 Knowledge User licenses so I'll be able to allow one more person to create and edit.  Haven't ID'd that person yet however.

To do more than read articles, agents need the Knowledge User license.

  1. From Setup, enter Users in the Quick Find box, then select Users.
  2. Click Edit next to the user's name or click New to create a user.
  3. If you are creating a user, complete all the required fields.
  4. Select the Knowledge User checkbox.
  5. Click Save.

The guide gives a good explanation of the options listed here.  Here are my setting based on what I know about our company.  For instance, we have a partner community for one of our partners in APAC so we'll make the article summaries visible to them. 







We have support agents in Europe and Asia.  I'm currently gathering information regarding the language requirements in those regions.   Sticking with Single Language for now since you can't go back once Multiple is selected. 
*Received feedback from UK Director.  Adding German as a supported language. 

Here's the last image of the current settings.  If any changes are applied I'll note that below. 





Now for adding that marketing email communication as an article. 

Enable knowledge for a knowledge user...

Setup, Users, edit user, Check 'Knowledge User', Save

Create article types

Setup, Article Types, Create New...

Great video found on YouTube





Creating a New Article was pretty self explanatory except for the fact that you must (most likely you must) create a custom field for rich text.  The standard fields aren't really sufficient for creating articles.   Found this out watching the video above. 


other sections to consider still...


Create Custom profiles for Knowledge Users - or permission 


Why can't my user see the Knowledge tab?!?!?!?

Well, after about 30 minutes of digging I found the answer...


  1. Make sure the Knowledge object is available to the user either through Profile settings or a Permission Set
    1. ...Setup | Profiles | 'select the profile' | Object Settings | Knowledge | make sure it's not 'Tab Hidden' 
  2. Now for the potentially confusing part.   Do the same thing for your Knowledge Articles you want the users to see.  In order for the user to have access to the Knowledge tab they must have 'read' rights on at least one Article AND the Articles are represented as 'Objects' for Profiles or Permission Sets to enable. 
    1. ...Setup | Profiles | 'select the profile' | Object Settings | 'Article Name' | Need 'Read' permission at a minimum
* page 13 of the guide.  8th bullet point...  8. Ensure each user has at least a Read permission on at least one article type.

Thank you Atul Gupta for the answer on the Salesforce Success Community


sets...Add Knowledge-related tabs to apps. Add Knowledge-related data to page layouts.Create Data CategoriesSet Visibility of the Data CategoriesEnable Feed Tracking on Article Types








17 June 2016

Creating Matching and Duplicate Rules w/ Native Duplicate Management Features

I just updated the Matching and Duplicate Rules in our Salesforce org so I thought I'd post about how it was originally set up and the small changes I recently made.

We have a duplicate data issue.  Currently support reps think nothing of creating duplicate or incomplete contact and account records to fulfill their cases.  Case creation and tracking is just a tool to count activity.  It's not used to provide feedback to the product team for feature enhancement, nor the sales team for more intelligent onsite conversations with customers.    I'm looking to change this.

When I started here there was a little-used app called DupeCatcher.  I hadn't heard of it so, before uninstalling I wanted to check out the product.  Turns out a lot of the functionality (a lot of the functionality we used anyway) was in the native 'Duplicate Management' features of Salesforce.   So I decided to scrap DupeCatcher and build out the Salesforce settings instead.  If anyone using DupeCatcher wants to post about the product's enhancements, please do.

Here's a good summary of Duplicate Management 

First...  Create your Duplicate Rules.   Here are mine.


Only Account and Contact Dupe Rules are active.

For our Accounts in the US with Bank as the type we map them to their FDIC numbers.
So, I've created rules to not allow duplicate FDICs, CCIDs (unique fields from an external database) and, recently, Account Name.
We do have accounts with the same name however I think it'll do more good than bad to not allow creation of the same account name twice anymore.  More often than not the account created with the same name is a duplicate as opposed to another account with the same name.  Example; First Southern Bank.  There are definitely a few of these in the country but most of the bank with this issue are already in Salesforce.



One of the recent changes I made was to block any duplicate account creation.   You can choose to allow the rep to Save the new account and ignore the notification of the duplicate account.  I took away that option since there should be absolutely no duplicate FDIC numbers or CCIDs.


I'd suggest doing this in your org too if you haven't already.   Even as I post this I think to myself, of course I should've enabled this in the first place.

Next I'll see if the fuzzy logic on the Contact Name will suffice.



With these criteria users can try to create a contact named Rich Higgins on a specific account and Salesforce will block it if Richard Higgins exists.

If you have any suggestions on keeping data clean beyond these duplicate rules I'm all ears.



From the Salesforce help pages.

Create or Edit Duplicate Rules | Salesforce

Create or Edit Duplicate Rules


Use duplicate rules to define what happens when a user tries to save a duplicate record.
Available in: Salesforce Classic and Lightning Experience
Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions
User Permissions Needed
To create, edit, or delete duplicate rules:“Customize Application”
To activate and deactivate duplicate rules:“Customize Application”
To view duplicate rules:“View Setup and Configuration”
In order for users to see the list of possible duplicates detected by the duplicate rule, they must have read access to the object defined in the rule.
  1. From Setup, enter Duplicate Rules in the Quick Find box, then select Duplicate Rules.
  2. To edit an existing rule, click the rule name, then click Edit. To create a new rule, click New Rule , then select the object you want the rule to apply to.
  3. Enter the rule details, including the rule’s name, description, and record-level security settings.
  4. Select which action will occur when a user tries to save a duplicate record.
    If the action includes an alert to users, we’ll provide default alert text that you can customize. Only the Allow action includes the report option.
  5. In the Matching Rules section, first select the object that records will be compared with. Then select which matching rule will determine how records are identified as duplicates.
    The list includes all available matching rules for the selected object. If none of the matching rules in the list are what you want, select Create New Matching Rule.
    Tip
    We recommend you use the standard matching rules because they’ve been carefully designed to return the best possible set of match candidates. Just be sure you’ve activated them.
    If, however, you decide to create a new matching rule, we recommend you first finish creating your duplicate rule. Then create and activate the new matching rule. When you come back to the duplicate rule, it will automatically have the newly created matching rule associated it, as long as it didn’t already have an associated matching rule.
  6. Make sure you’ve selected the field mapping for each matching rule, if needed.
    If the matching rule is comparing records from two different objects or uses custom fields:
    • You’ll need to decide how you want the fields from the first object to be compared to the fields from the second object. For example, you might map a custom field called Work Email to the standard Email field.
    • Some data may be truncated prior to matching two text fields with different maximum lengths.
  7. If you want your duplicate rule to run only if specific conditions are met, specify the conditions.
    For example, you could add a condition that tells the rule to run only if the record was entered by a user with a certain profile or role, or if the record includes a specific country or state.
  8. Save the rule.
  9. Activate the rule.
    For the activation to succeed, all associated matching rules must be active.
  10. If you have more than one active duplicate rule for a particular object, you may want to adjust the order in which the rules are processed. You can reorder rules by clicking Reorder from any rule’s detail page.
    Tip
    If the first duplicate rule finds a match for a particular record, that record will not be evaluated by subsequent duplicate rules. Therefore, you should order your duplicate rule so that rules with the Block action are run before rules with the Allow action.




Create or Edit Custom Matching Rules


Use matching rules to determine how two records are compared and identified as duplicates.
Available in: Salesforce Classic and Lightning Experience
Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions
User Permissions Needed
To create, edit, or delete matching rules:“Customize Application”
To activate and deactivate matching rules:“Customize Application”
To view matching rules:“View Setup and Configuration”
  1. From Setup, enter Matching Rules in the Quick Find box, then select Matching Rules.
  2. If editing an existing matching rule, make sure the rule is inactive.
  3. Click New Rule or Edit next to the existing rule you want to edit.
  4. Select which object this matching rule will apply to.
  5. Enter a name and description for the rule.
  6. Enter the matching criteria.
    The matching criteria is where you define which fields to compare and how. To add additional fields (up to 10 total) click Add Filter Logic... and then Add Row.
  7. If you need to adjust the matching equation, click Add Filter Logic.... Here you can, for example, manually change an AND expression to an OR expression.
  8. Save the rule.
  9. Activate the rule.
    The activation process may take some time, so we’ll send you an email when the process is complete and your matching rule is ready to use.
After the matching rule is active, it’s available to use with other Data.com Duplicate Management tools. For example, using a matching rule with a duplicate rule tells Salesforce to take certain actions when users try to save a record the matching rule has identified as a duplicate.

15 June 2016

Auto Assign Team Members

** this blog has been moved to Sites

This Process and Flow combination automatically assigns team members based on the region of the account.  See my previous post regarding the region field population.  Formula for Regions

First, thank you to Derek Davis providing the structure of this flow.  I basically filled in the blanks.  The Flow...



We have mixed team members.  A RAM and an AE are assigned to each region regardless of the type of account it is. (ex. bank, accounting firm, law firm, ect...)
And a responder rep is assigned to the team IF the account is a Bank record type.  Responders are based on region as well.

So we lookup the account info...


And get the RecordType and Region from the lookup. 

Next we Fast Lookup the Account and identify the current team members. 



We want to different paths.   One path if there are team members on the account currently.  And another path if there are none.  So, Decision...


If the team member does exist we're going to delete them...


If they don't exist we're going to assign them based on the region.   So another decision to find the region.   This is the path after the team members are deleted too. 



Create the RAM member and AE member...







Then, if it's a bank, check the region and assign the responder reps.








If the team exists it's deleted and the team is re-added to the account.   This 'check' by Salesforce is ONLY done if the Region field IS CHANGED.   As shown in the process builder screen shots below. 





That's it.  No more having to run reports, check the team members are correct, export and correct a csv file and then upsert the correct teams.,





Process Builder and Visual Workflow data from the Salesforce help site.

Lightning Process Builder

Many of the tasks you normally assign, the emails you regularly send, and other record updates are vital parts of your organization's standard processes. Instead of doing this repetitive work manually, you can configure processes to do it automatically.
Available in: both Salesforce Classic and Lightning Experience
Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions
The Process Builder is a workflow tool that helps you easily automate your business processes by providing a powerful and user-friendly graphical representation of your process as you build it. The Process Builder’s simple and powerful design allows you to:
  • Create your processes using a convenient layout with point-and-click efficiency.
  • Create your whole process in one place rather than using multiple workflow rules.
  • Create processes by collaborating with different teams in your business.
  • Stop using Apex code to automate simple tasks.
Automated processes in the Process Builder are based on records and consist of:
  • Criteria that determine when to execute action groups.
  • Immediate and scheduled actions to execute when those criteria are met.
Any change that causes a record to match the criteria can automatically trigger the action group. A single process can also execute multiple action groups—so it’s easy to automate all of your business records, like accounts, in one place.
You can use the more powerful and flexible Process Builder to perform the same actions as workflow. With the Process Builder, you can:
  • Create a record
  • Update any related record—not just the record or its parent
  • Use a quick action to create a record, update a record, or log a call
  • Launch a flow—you can’t schedule this action with workflow
  • Send an email
  • Post to Chatter
  • Submit for approval
If you need your process to do more than what those actions allow, don’t worry. You can also call Apex or a flow from a process.




Visual Workflow

Visual Workflow lets you automate business processes by building flows and distributing them to the right users or systems. A flow is an application that can execute logic, interact with the Salesforce database, call Apex classes, and collect data from users. You can build flows by using the Cloud Flow Designer.
Available in: both Salesforce Classic and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions
Flows can either require user interaction—perhaps a wizard or guided UI for data entry—or run in the background on their own—perhaps something that automatically transfers records when a user’s role changes.







Support team - Auto Case Closed

The Customer Support team is tired of hitting Save on a Case and then Closing it on the Case Closed page.
Creating a process to automatically mark a case closed when it's saved.

Overview of the Process:



Only when the Case is created



Just do it. 



Update the Status field to Closed



Now when a Case is Saved...


It's updated to Closed Status...