In the last post, we introduced the new Lightning Process builder and looked at the simplest use case of updating the current record. Today, we want to take a look at a relatively common need: updating or creating related records when certain conditions are met on the current record.
Deactivating related records
As an easy example, we’ll build upon the concept of deactivating records we discussed in this post. In our case, if we deactivate an Account, we want to automatically deactivate all child Contacts as well. Using a Process, this task is straight forward.
To begin, we’ll create a new Process:
Next, we’ll add the Account object as the target object and set the criteria appropriately:
Finally, we’ll add a new action to set the Active bit on all related Contact records to false as well:
For good measure, we can do the opposite operation when records are reactivated:
With just these few clicks, we’ve created a powerful new process that will help us enforce data integrity across objects.
Creating Related Records
Updating related records is fine, but we can go further. Imagine we have a requirement that whenever an Account is deactivated, we need to store who deactivated the record and when for auditing purposes. To show off Processes, we’ll create a new custom object related to Accounts that stores this information:
For this example, we’ll be using the CreatedBy to track who changed the status, and the native CreatedDate field to track when it happened.
We could create a new Process to handle this, but since we already have one that deals with Accounts being activated/deactivated, let’s reuse that instead. This helps keep our number of Processes we have to maintain to a minimum, and makes it easier to reason about what is happening when in the system.
Going back to our process, we can add a new Immediate Action for when an Account is deactivated to create a new Account Status History record related to the Account:
Doing the same for the Activate branch and we now have an audit trail built using Processes:
This highlights two important things to note about Processes:
- Just like workflows, we can take multiple actions when a record reaches a given state. Combining processes makes it easier to understand what criteria cause what groups of actions, so we recommend keeping your processes as combined as possible, while still making them readable and understandable.
- Processes allow us to do some new actions which previously would have required Apex code (like creating related records). This is a big gain for system administrators as they now have another tool with which to meet their business requirements.
Today we saw that Processes can take us beyond workflows by allowing us to update and create related records without having to write any custom code. They also allow us to take multiple actions, just as with workflows, so that we can combine our logic to keep it as clean and understandable as possible. However, this isn’t all they offer us that’s worth exploring. Stay tuned as the series continues and we explore another set of features!
One of the biggest, if not the biggest, feature in the Salesforce Spring ’15 release is the Lightning Process builder – a totally new way for us to build point and click logic that runs in our organizations. The builder is a rethinking of how workflows should function and provides us with a range of new possibilities that would have previously taken triggers and custom Apex code to accomplish. In the coming series, we’re going to be taking a deep dive in to the Process builder to see what’s new, what’s old, and what’s just plain cool.
Baby’s first process
To begin, we need to know how to get to the builder and create a process. After you have logged in to an organization, you can get to the builder by following Setup > Create > Workflow & Approvals > Process Builder.
Once you click on the link, you’ll be taken to a new page with a very different kind of UI:
This is the new process builder UI. On this page, you’re given some basic information on what you can do as well as a few helpful links.
To demonstrate the power of the process builder, we’re going to build a few sample processes. Today, we’ll assume that our requirements are:
- When an Account is created or updated
- If the Type is Prospect, we want the Industry to be Agriculture
- If the Type is Other, we want the Industry to be Banking
- If the Type is anything else, don’t change the Industry
Before we dive in to the Process Builder, let’s take a moment to remember how we would normally approach these kinds of requirements.
The most straight forward way would be to create two workflows: one for each of the two Types we want to handle (Prospect and Other). Each workflow would have its own field update action which updates the Industry to the known value. This works, but does have the downside of the logic being split between two unrelated workflows. This isn’t a huge problem if you only have two workflows total, but if you have dozens or hundreds of workflows, it can be difficult to figure out what workflows are related to what other workflows, and to debug why they might be interacting with each other.
As an alternative, we could create one workflow that checks for both of the types, and then uses a formula to figure out which value to set Industry to. This works, but isn’t as readable as using the two workflow approach. It also doesn’t scale well if you want to create a workflow that deals with more than just a few values.
Let’s look at how a Lightning Process would solve handle these requirements.
On the process builder, clicking the new button brings up a page for us to name our new process and optionally enter a description about it. Once we fill in these fields we’re taken to the main screen of the builder:
Here, you can see that processes are laid out as flow charts, and we build processes by adding and modifying the elements of the flow chat.
To begin, we’ll tell the process that we want to act on the Account object by clicking the Add Object box:
Then selecting Account as the object. In our case, we want this process to run if a record is updated as well as created, so we’ll choose the second option under Start the process.
Leave the other options as the defaults for now and click Save.
Now that we have a processed based on Accounts, it’s time to start adding some logic to it. We’ll handle the Prospect type first by clicking Add Criteria to add a new Action Group (a set of things to do if some logic is true).
The resulting screen should be pretty familiar to anyone who’s built a workflow before, most of the options are the same and it uses a very similar layout. I’ve built out what we’ll need for our first group already:
Notice the very last check box – this tells the process to only execute this branch of logic if the current set of changes made these filters evaluate to true. Without this check box enabled, this logic will run any time the record meets this criteria, regardless of if the change made to the record had anything to do with the filter or not.
After we click save, we’re able to start adding actions if the filter criteria evaluates to true:
Clicking Add Action brings up a new screen that is again similar to building an action for a workflow to take. For now, we’ll create an Update Records action and give it a fitting name:
The next part is a little tricky, when you click the Object drop down you’re presented with a layover (which is a little confusing from a UI perspective…). In this layover, you would expect the Account’s fields to be in the dropdown box:
But in actuality if you click on that dropdown box, you’ll only find the relationship fields.
This is happening because what you’re actually selecting here are the objects you want to update, which hints at something more powerful than we’ve seen before – the ability to update all related records of your current record. We’ll revisit this idea in a future post.
While it doesn’t look like you can, you can actually click on the text ‘Account’ to select the current Account record as the record we’re going to update.
Once we click save, the rest of the screen is fairly straight forward:
Click save, and we’re done with this branch of logic.
Going beyond workflows
At this point, we haven’t built anything we couldn’t have done with a workflow. Now, we’re going to build out another branch of logic which handles the “Other” type within the same Process and you’ll begin to see why Processes are so powerful – we can effectively combine multiple workflows in to one and still have them be readable and maintainable.
The steps are almost identical and final process looks like:
We could keep adding logic branches – the more we add the more benefit we get from using a Process over a workflow. Once we’re done building a Process, we need to activate it (just like with workflows) for it to do anything.
This is just a small taste of the new power Processes give us, but hopefully you can see their usefulness already. Stay tuned and we’ll take a look at some of the more advanced things you can do with Processes that will help simplify and automate your organizations.
Have a question? Confused about something we wrote? Need help figuring out how to automate your organization most effectively? Contact us and we can help.
- Lack of ownership
- Lack of system management
- Lack of priority on project's success
- Inadequate planning and road-mapping
- Specific partner shortcomings
Maybe your previous partner over-promised and under-delivered. Perhaps there was a lack of planning and poor communication that led your system to its inevitable downfall. Maybe the final product could be described as lackluster at best; it looked great but it didn't really do anything. Or maybe, the project went swimmingly and you're elated with the final product but no one is using it.
Regardless of the reason, we've seen and rescued our fair share of poor CRM deployments. If it makes you feel any better, you're not alone.
If your previous attempt at CRM left you with a plundering system and an overall sense of frustration, don't give up just yet. A well implemented CRM can do much more than manage prospects, contacts, and sales pipelines. A successful CRM system can help you meet your company's business objectives and ensure that you compete successfully over time.
Download our new eBook, The Trail to CRM Triage, and follow these five steps to guarantee CRM success the second time around.
Today's post is written by Richard Failla, a Salesforce Business Analyst at Sonoma Partners.
One of our clients recently asked us to design a survey solution for them. At that time, they had a separate system they used to manage, administer, and report on customer satisfaction surveys. Much of this work was done manually, especially the reporting piece, which involved some heavy Excel crunching. Our project goal? Use Clicktools to create a more automated solution that brought survey data into Salesforce, thus creating a more holistic customer picture.
After reviewing the requirements I noticed some common issues when implementing a survey solution that would require some creative approaches.
The Problem: “Surveys need to be personalized for each of our clients.”
Since you need a custom field for any survey question you want to pass back into Salesforce, there’s a problem of rigidity: how do we build a solution that allows survey questions to be customized without needing to constantly add new custom fields? The trick was to take each survey question and ask, “What metric does this question probe?”
The Solution: “Don’t fixate on specific survey questions, group them into question themes.”
Let’s look at an example question from a survey:
“Our team is responsive and acts with a sense of urgency."
Mapping that question verbatim to a custom picklist field would make it inflexible and cumbersome to manage for an admin should the question change in subsequent surveys. So instead, we created a custom picklist field and called it “Responsiveness.” Mapping the question to a more general theme allows the flexibility to change the wording of the survey question without having to manipulate the metadata it maps to. So we apply this logic to all relevant survey questions. Here’s an example:
Now, in a future survey we can change the wording of the question in the CMS without having to change it in CRM, so long as the question still gets to the heart of the metric we’re after.
The Problem: “Each new survey must be re-mapped by an admin.”
The value of automating survey data into Salesforce comes with a cost: each new question/survey you want to ask needs to be re-mapped to Salesforce. This takes unnecessary time to plan and coordinate with admins and can easily delay pushing out surveys. While not ideal, it’s doable if you have an admin but without one this solution looks less sustainable over time.
The Solution: “Create a master survey template.”
Using Clicktools, we created a master survey template. This template included every single question theme across all surveys. To clarify, no survey questions were added to this template - only the themes we created back in Salesforce.
One of the great things about Clicktools is that it allows you to hide questions on surveys. By hiding all questions, users could use this template to create new surveys by simply replacing the theme with the specific question they wanted to ask and un-hiding the field. Since this master template has already been mapped to all themes in Salesforce, admins would never have to re-map. We also took some time to think through questions themes that could come up in the future but aren’t necessarily on any current surveys and included them in this master template.
The Problem: “Feedback should be collected for any response that scores poorly.”
Client feedback can help you identify areas in need of improvement but to eliminate the guesswork in rectifying the problem, you need to know why you’re not meeting expectations. For our solution, we could have dropped into the survey optional open-ended feedback boxes after each question but that only muddies an otherwise simple form.
The Solution: Creative dynamic question conditions in Clicktools
A neat feature in Clicktools is the ability to dynamically pop questions onto the form based on a
certain condition. In our case, for any response that scored “Neutral,” “Disagree,” or “Strongly Disagree,” we popped an open-ended feedback box.
So we actually created an open-ended feedback box for each question on our master template (and likewise, created these in Salesforce). Since these questions appear dynamically, there’s no need to “hide” them on the master form thus alleviating admins from more manual manipulation.
The Problem: “How do we use calculations to assess our performance if our response options aren’t numbers.”
For the majority of questions in our survey, respondents had the following values to choose when answering:
- Strongly Agree
- Strongly Disagree
- Don’t Know
These options make it easy to map to picklist values but we lose native reporting functionality if we leave them like this. What happens if you want to see the average score for a particular question over time?
The Solution: “Use formula fields to convert picklist values to numbered scores.”
Without this formula we’d have to either change the survey response options to numbers (which may not be an option) or settle without basic reporting functionality for trend analysis. With this formula, we can both preserve the original survey and still leverage native report summarizations in Salesforce. So we apply this logic to all survey theme questions in Salesforce:
There’s nothing crazy here, but this little formula allows you to leverage native reporting functionality in Salesforce without compromising the original survey.
The Problem: “What’s the top-box and top-2-box score for a particular group of questions?”
If you don’t know, the top-box is the most positive response possible for a given survey question. Subsequently, the top-2-box is any question that scores at least the second most positive response. To determine these scores, we used the following formula:
Total Number of Top-Box Responses / Total Number of Responses
We knew there was some combination of field and report formulas but we scratched our head a bit to figure out how to tie it all together.
The Solution: “Create parent groupings for your question themes and reference them in formulas.”
In order to begin designing a solution to this problem, we had to bundle our themes into parent groupings called “dimensions.” At these dimension levels is where we would apply our top-box scores. For example, we grouped the following question themes into a dimension called “Relationship":
We created three other dimensions and grouped all themes to one of these. We then used 5 formula fields for each dimension to calculate the scores.
Now we needed to find how many of those questions contained either a top-box or a top-2-box response.
Here’s the formula for the number of top-box questions:
At this point, we had everything we needed to calculate our top-box scores, so we created two more formula fields.
Collecting customer feedback in Salesforce requires some consideration before implementation but with only native functionality we were able build a flexibly dynamic solution that requires minimal admin intervention, automates reporting, and can be easily manipulated to account for new surveys in the future.
With CRM 2015 Microsoft added the ability to customize help content on a global level as well as an entity level. Your content will then be surfaced by clicking the question mark icon at the top right of CRM.
Depending on what entity grid or form you are on, CRM will either take you to the custom help URL specified for that specific entity or if a URL isn’t specified then it will take you to the custom help URL specified at a global level with context information passed in as a parameter. If a custom help URL isn’t specified at an entity or global level then it will display the native CRM Customer Center.
To setup custom help at a global level:
- Go to the System Settings in CRM (Settings –> System Settings)
- On the General tab, scroll down towards the bottom to find “Set custom Help URL”
- Set “Use custom Help for customizable entities” to Yes
- You can now specify a URL in the “Global custom Help URL” field
- This URL can also be a relative path to a custom web resource, for example: /WebResources/new_/help/content/global.htm
- Set “Append parameters to URL” to yes if you would like the following context information to be appended to your custom URL
- User Language Code: userlcid
- Entity Name: entity
- Entry Point: hierarchy chart or form
- Form id: formid
To setup custom help at an entity level:
- Navigate to the entity information in the solution
- Check the “Use custom Help” box
- You can now specify a URL in the “Help URL” field
- This URL can also be a relative path similar to the global custom help, for example: /WebResources/new_/help/content/account.htm
- Publish Customizations
Microsoft released the much anticipated Update Rollup 2 for CRM 2013 Service Pack 1. The download page can be found here - http://www.microsoft.com/en-us/download/details.aspx?id=45518. The version for this update will start with 6.1.2.
Microsoft didn’t hold back with this release. The update is jam packed with over 100 fixes! A few pesky Generic SQL Errors have been fixed, one that can occur when synchronizing to Outlook as well as a random SQL deadlock when trying to update Opportunity Products. In addition, there are a variety of other fixes ranging from hard errors to performance issues. For the full list of resolved issues, head to the KB article - http://support.microsoft.com/kb/2963850.
As always, be sure to install this update in a development or sandbox environment to test your functionality before installing it to production.
One of the things we see and hear from clients who are migrating from Microsoft Dynamics to Salesforce.com is that they miss the ability to just deactivate records rather than having to delete them. They would like to be able to keep their old data, but they only want to look at it when they want to do historical reporting. There are many ways to do this kind of ‘archiving’ of data, but today I’m going to talk about one approach we’ve used that relies only on the core Salesforce platform – no extra apps or licenses needed.
Tracking inactive records
Natively, Salesforce doesn’t have any concept of ‘inactive’ records for most entities. We can build in this concept by adding a custom checkbox field called inactive:
The idea here is that to deactivate a record, you can check this checkbox. We’ll also update any views in the system to filter out records with this checkbox by default, so users won’t see these records.
With these few changes to our system, we can handle most of the basic use cases for our users in relatively little time. However, we do still encounter one problem:
If you create a record and set it to inactive:
And then search for the record from the Global Search, you still get the record back:
From this screen, you can’t tell if the record is active or inactive. Ideally we’d like to filter out inactive records from Global Search as well, but currently there is no way to do this. We have a couple of options at this point, depending on the client’s needs and wants.
One solution is to modify the Search Layout for each object to also include the Inactive field we added. While this doesn’t allow the users to filter the results, it does give them an indication of which records are active or inactive:
Then you can customize the filters for all users for a given object to include the Inactive field:
Once this is complete, when a user searches for the records, they will have the ability to filter out inactive records by manually updating their search criteria:
This solution is clean in terms of the data being stored and used as intended, but it does rely on the user actively checking the Inactive column or filtering out the results they do not want to see.
Using a workflow field update
Another common solution is to rename the record to something to indicate that the record is inactive, usually something along the lines of “INACTIVE “ + name. We can accomplish this with two workflows per object: one for when the record is marked inactive and another for when it’s marked active.
The inactive workflow will prepend the name with the word INACTIVE and looks like:
The active workflow will strip out the “INACTIVE” portion of the name whenever the record is reactivated, and it looks like:
As with all workflows, don’t forget to activate them after you have created them.
With these workflows in place, when we go to a record and deactivate it, the name will update:
And when we search for the record in Global Search we can quickly tell which records are inactive:
Updating the record back to active also works as expected:
These are just two of the many options we have for tackling this kind of request. Neither is perfect since we can’t filter what records are returned by Global Search (vote for that idea here). Need something more complicated, or have a different issue you would like some help on? Contact us and we can help.
Jones Lang LaSalle (JLL) is a financial and professional services firm that specializes in commercial real estate services and investment management. With an impressive workforce of 52,700 employees spread across 200 corporate offices worldwide, JLL turned to CRM to improve visibility into the core business of real estate availability. But with their original out of the box solution, sales reps found CRM to be cumbersome and difficult to navigate. Information about real estate availability wasn’t always accurate within CRM and too much information on each screen was a point of confusion for end users. What they needed? A customized global deployment of Microsoft Dynamics CRM.
“If we are going to remain a thought leader in commercial real estate, it’s crucial that we not only have the right data analytics tools, but also have systems that are agile and flexible.”
- Greg Adams, Managing Director of Information Technology for JLL
Today, JLL uses Microsoft Dynamics CRM, SharePoint and Office 365 to get the job done. But for JLL to grow, they needed agility and flexibility - two things the cloud could give them.
The following is an excerpt from the full customer story published by Microsoft:
JLL used Microsoft Dynamics CRM on premise for several years, but is working now to add 3,500 Microsoft Dynamics CRM online seats to their current 2,000, allowing their offices in Asia, EMEA, Australia, the US, and beyond to have access to the same data analytics tools and more seamlessly integrate across continents. They envision their Microsoft Dynamics CRM system as a hub of information for their properties, accounts, and services so their people not only have the right information, anywhere, on any device, but also can be more proactive in their discussions with customers. The company is also planning to move its full Microsoft stack to the cloud, and is considering adding Microsoft Social Listening.
“With a company our size, you have to have customizations around business processes – both for individual offices and across the entire company.” Adams says. “As we look to the future, if it can’t operate in the cloud, we will probably look elsewhere.”
Among the many exciting features of the upcoming Spring ’15 release there is a hidden gem for developers coming: the new @testSetup annotation. This new annotation will let you refactor chunks of code common to each test within a test class in to a common setup method that is guaranteed to be called before each test method is run. When combined with a Factory pattern to actually do the creation of test data and settings, this becomes a powerful way to organize your code so that it is easy to read and understand, and consistent across projects.
Trying to remain DRY
Historically, unit tests have been a difficult place for developers to remain DRY. There are several solutions for this, but most get ignored or are underutilized due to the overriding need for unit tests to be exceptionally readable. Testing software is notoriously difficult, and anything that attempts this in an automated fashion needs to be simpler, more readable and more maintainable than the software it is testing – otherwise you may need to start testing the tests! Generally, the lack of patterns and desire to remain simple and readable leads to the opposite of what we would want in any other part of our code base: repeated code. It’s not uncommon to see code like the following, with repeated setup code at the beginning of each test method:
Oftentimes, developers will see this repeated code and attempt to remain dry by refactoring the code into a helper method which gets called at the beginning of each test:
While this mostly works, what we’d really like is for the framework to handle this for us so that we can avoid having to put in the extra method calls if possible.
@testSetup – removing repeated code
@testSetup is a new annotation that will allow you to specify methods that the test framework will run just before each test method runs. The test methods must return null and be static (similar to most other testing frameworks) but otherwise can do whatever is needed by your tests. This annotation is totally optional as well, so if you don’t need/don’t like it you don’t have to use it. Continuing our sample from above, we can refactor the code base to:
By being able to gloss over the setup details, the next person who has to maintain these tests can more easily focus on the core concept each method is trying to test hopefully promoting more reliable and robust code.
We are excited for this new annotation and will be exploring its creative uses when it’s released. As with any new release there are some important caveats to it, so we encourage you to read the documentation on it before attempting to refactor any existing code bases. If you are confused by this or want to know more, feel free to leave us a comment below or contact us!
Today's post is written by Andrew Monshizadeh, an iOS Developer at Sonoma Partners.
In the first blog post we discussed a situation where it would make sense to split part of a Visualforce page out into a component, and in the second blog post we actually did the work of that split, ending up with an easily reusable component. This time we will discuss a few more advanced uses for a Visualforce Component.
Another great use for components are buttons that can be used throughout the customized application. Consider a situation where potentially a customer requires a set of Visualforce pages that provide a progression for users. The progression log could be completely stripped from the process pages and moved to a single component. In the example below, this is accomplished by making the component take in the name of the previous and next pages in the progression, then passing those strings into the PageReference(String) constructor. With this pattern, each page only needs to know the name of the previous and next page, but nothing about how to make that transition.
Lastly, the most complex, but potentially most useful use for Visualforce components: components that can take care of formatting values and then pass those back to the containing Visualforce page. This pattern requires a little more setup than others, but provides so much potential it is easily forgiven. For example, consider that the client wants users to enter names in numerous locations in various Visualforce pages, but each name field will have the same kind of formatting of the input. Look over the screenshots and code below, and then reference the steps that follow for the explanation.
Figure 6 - Page after loading
1. Create a class named DataWrapper. This class will wrap the values you want to pass between the containing Visualforce page's controller and the component. The reason this class is necessary is that by default primitive data types are passed by value and thus copied from the container page's controller to the component, while objects are passed by reference. This matters because a copied value no longer will update the original value. Note that it has only the one internal property, this is all we really want and need, but it must be in an Object so we get the by reference behavior.
2. Create a component named NameInputTextComponent. This is where we will encapsulate all of the formatting logic. The component is not complex for this example, it has one attribute that takes in a DataWrapper type of object, the one <apex:inputText> tag with a <apex:actionSupport> tag. The input is pretty self-explanatory, while the action support tag is used to fire off the formatting function when the input field loses focus.
3. Create a controller for the component (NameInputTextComponentController). This is where all the heavy lifting will be done. It will have a property with the type DataWrapper, a String property to actually be referenced in the component and a method to do the formatting. As discussed before, the formatting method is called by the <apex:actionSupport> tag after the input field loses focus. The input field is bound to the String property, and so gets and sets data to that property. The formatting function is the function that puts the formatted data back into the wrapper.
4. Create a page and controller where this component will be used (NameInputTextPage and NameInputTextPageController, respectively). In the controller is a property of the DataWrapper type, and lazily instantiate it with some wrapped String value. The lazy initialization is not required, but a good habit. Also in the controller is an action function that will be used just to demonstrate that the values that are truly being updated in the component and containing page.
With this simple component, a developer would be able to provide the formatted name fields wherever necessary. For example, the developer could provide a page where users are able to enter some number of names in a table format, click a button, and that number of Contacts are created. With this component, the client could be sure that all of the names would be formatted correctly.
Finally, that simple demonstration should showcase the power of components. They are able to do some pretty heavy lifting, and remove some of the maintenance headache that is part of large Visualforce customization by encapsulating and reusing pieces throughout.
Have questions about Visualforce Components? Let's set up a time to talk.
Today’s post is co-written by Kevin Yamashita, a Senior Quality Analyst at Sonoma Partners.
With the release of Dynamics 2015, we're excited to announce that our community applications (Editable Grid, Universal Search, Dynamic Forms) have been updated and are now compatible with CRM 2015. As always, these tools are available for both on-prem and online deployments for free!
CRM 2015 introduces Multi-Entity Search functionality for the Web client and also enhanced their Business Rules feature. You may wonder how that impacts Universal Search and Dynamic Forms. Let’s compare each of our community tools to those new features so you can decide which tool will best suit your needs.
Universal Search (US) vs Multi-Entity Search (MES)
|Feature||Universal Search||Multi-Entity Search||Notes|
|Search Configuration||Native Quick Find View||Native Quick Find View||Both solutions use the Quick Find View to configure the search and return columns|
|Entity Support||Unlimited*||10 max||* We still recommend limiting to a reasonable number for performance|
|Results Display||Configurable – unlimited fields from Quick Find*||Configurable - first 3 fields of Quick Find||* We still recommend limiting to a reasonable number for performance|
|Tablet Client Access||No||Yes|
|Web Access||Application menu||CRM masthead||MES will always be available for users, while US may not depending on how CRM displays the application menu buttons|
|Related Record Access||Yes||No||US allows a user to click a link to a related lookup record when returned in the search results|
|Filter Data Search||Yes – using record createdon date||No||In addition to the native Quick Find configuration, US allows you to filter based on the record createdon date, which can improve performance for large data sets|
As you can see from the above comparison, the native multi-entity search now provides much of the same functionality as Universal Search. And with MES’s ‘always available’ placement in the masthead & tablet client support, we recommend starting with MES for your implementations. Since Microsoft made it easy for us to update our 2013 solution for 2015 and a couple of differences still remain, we thought we would keep it available as a free download.
Dynamic Forms (DF) vs. Business Rules (BR)
|Feature||Dynamic Forms||Business Rules||Notes|
Error Message Dialog
Error Message Dialog
|Related Entity Reference||Yes||No|
|Else If Logic||No||Yes|
|“And” or “Or”||No||Yes||BR allows for the use of "and" or "or" logic between conditions, while DF supports only "and" logic|
|Event Triggers||Client-side||Both client and server side|
|Number of Rules||10*||Unlimited||* The free community edition allows you a maximum of 10 rules.|
Unlike Universal Search, Dynamic Forms continues to have advantages, particularly with the number of extra conditions that DF provides. We recommend you consider the functionality you need to provide and decide on the best tool to accomplish it. When you can, keep using the native tools that Microsoft provides and then augment the gaps with DF.
Also, note that our latest solution file downloads for CRM 2015 also should import to CRM 2013 (you should see both versions in the download zip file name).
Today's post is written by Richard Failla, a Salesforce Business Analyst at Sonoma Partners.
We told you why we’re excited for Spring ’15 but now we want to dive deeper into one long-awaited feature: native Duplicate Management. While it technically falls under Data.com, it does not require a separate Data.com license to use. So if you’re running Professional Edition or above, follow along as we detail some specifics you can expect when the switch is flipped in your org.
It’s a Plumber, Not a Cleaner
Once enabled, the feature essentially creates a barrier for duplicate records to enter your system. It will not scrub your org for existing duplicates in the first release but we’re hopeful to see this enhancement in the future.
Not All Dupes Are Created Equal
In addition to Accounts, Contacts, and Leads, native Duplicate Management will work with custom objects. It’s good to see support for the core standard objects but adding in custom objects is a huge win for those with more complex orgs.
One Of These Things Is (Not) Like The Other
Any dupe-detection solution requires matching rules and often those rules need to compare data between standard and custom fields. But often we need to go further and cross data between objects. Is your new Lead already a Contact? Crossing standard and custom fields is core to managing duplicate records but to extend the feature and support cross-object detection makes this more robust than anticipated for a first release.
Duplicate detection is nothing without the matching algorithm underneath. And rarely will an “exact match” suit our needs. With numerous ways to abbreviate a name, we need to be able to find a match between subtle distinctions like “Incorporated” vs. “Inc.” and 5-digit vs. 9-digit zip codes. The support for “fuzzy match” logic is a great feature to roll out of the gate and Salesforce has even provided preset matching methods to help us get started.
One API To Rule Them All
If you run a data import job via the API and a match is found for a given record, you’ll get an error and that record will not import. However, there is a new Apex Class that theoretically allows developers to force a save for matching records. That should help with those unique cases where you want to avoid turning off a rule just to tend to some admin housekeeping.
Search No More
Gone are the painstaking days of training end-users to search for existing records before creating new ones. Now when users try to save a new record, potential duplicate records can pop-up (if found). Users can then peruse these records and even edit the new record’s data on the fly.
Whether your end-users are entering records from their computer, phone, or tablet, native Duplicate Management is supported across all devices running Salesforce or SF1.
The “Silent Reporter”
Any dupe-detection solution brings to the fore the classic dichotomy between administrators and end-users; admins want quality data while end-users want pain-free data entry. Salesforce executed a solution that strives for balance between the two: rather than alerting end-users every time a potential dupe is found (or blocking their entry entirely), admins can now setup reports to track duplicate records on the backend without annoying end-users with popups and alerts on the frontend.
Duplicate Management is not a panacea; there are plenty of cases that demand more detailed dupe-detection capabilities. Nevertheless, we’re impressed to see all the nuances Salesforce has packed into the first release of their native Duplicate Management feature. Better yet, releasing it for free for Professional Editions and above goes a long way to help organizations looking to reduce dupes and maximize data quality without breaking the bank on 3rd-party solutions.
Today’s post is co-written by Kyle Gerstner, a Principal Mobility Architect at Sonoma Partners.
With the rush of the holidays, you may not have noticed that the Microsoft Dynamics CRM team released a new set of sample mobile code that demonstrate how to connect and interact with Dynamics CRM from Windows Phone, Android and iOS devices.
Microsoft asked Sonoma Partners to create a sample code solution specifically for iOS and Android developers. In these discussions, we wanted to showcase more than a simple mobile example connecting CRM. We believed we could come up with a quick, easy to understand reference application that leverages the code samples mobile developers would use in common applications, but also be immediately valuable to the user community. Our key solution tenants were:
- Provide framework for custom mobile applications
- Phone-based application
- Simple & common use case
- Stand-alone reference application
- No CRM solution changes required
We focused our use case on something every mobile user can appreciate: the ability to quickly find a contact’s details and record an interaction with that person. The results are the Activity Tracker phone sample application!
While we focused on the iOS and Android versions, Microsoft developed the Windows Phone in parallel, providing you the code to natively work with whichever device makes sense for your organization.
This starter application code was designed for mobile developers looking to get started with Dynamics CRM for the first time, as well as seasoned Dynamics CRM developers. Activity Tracker demonstrates how to find a contact and submit one type of activity interaction (a check-in task). However, the code is open source, so you have a framework to easily add additional activity types, brand the application to your color scheme, and also add additional entities (such as account and opportunity). You can also look to extend the use case slightly for more advanced scenarios.
To demonstrate, we have extended the application for our internal use to bring back tweets from a contact. We simply added a ‘Twitter Handle’ field to the contact form and use that to make a call to Twitter, retrieving all public tweets associated with that twitter handle. As you can see from the screenshot, we also altered the design of the activity history to use a horizontal scroll, for better usability with more information sources.
The Microsoft team also has demonstrated extending the application. They have a sample that enhanced the Windows Phone example to use Cortana – bringing the power of voice commands to your CRM data entry!
From a technical perspective, the samples show you how to connect to both the SOAP and OData endpoints that Dynamics CRM uses. As a mobile developer using Dynamics CRM, you will probably use both endpoints in your custom applications.
The OData endpoint is a more common approach for connecting mobile applications, and is the primary approach taken in this sample. For example, we use OData to fetch details of the contact and get the recent records list, which comes back in an easy-to-consume JSON format. However, not all of the Dynamics CRM API methods are currently supported with OData. One example of this, is using the Execute method which was needed to mark an activity as completed. Hence the need to also demonstrate how to interact with the SOAP endpoint.
We also made use of Microsoft’s ADAL library for Objective C and ADAL library for Android, which uses OAuth to authenticate the user to CRM. Like many mobile applications, this means your user authenticates from their appropriate authentication endpoint, with the credentials they already know and commonly use. More importantly from an application development perspective, the custom application does not need or has access to your username and password. The OAuth model gives the user and system administrators the ability to revoke access if a device is lost or an employee leaves the organization, helping to further reduce the security risks generally associated with mobile applications.
We believe these mobile samples will allow you to more quickly deploy a customized mobile application for your organization and make your mobile workforce more efficient and engaged.
Ready to mobilize your workforce? We can help. Contact us to learn more about mobile CRM applications for your business.
The following is a list of the new API methods from this MSDN article. We are particularly most excited about the ability to dynamically hide/show the business process flow control.
Change the process when there are more than one process available for the entity.
Use Xrm.Page.data.process.getEnabledProcesses to retrieve information about enabled processes that the user can choose for the entity. Then use Xrm.Page.data.process.setActiveProcess to make one of the enabled processes the active one.
Move to the next stage when all required steps are completed to make it the current active stage.
Move to the previous stage and make it the current active stage.
Select a stage to view the status of the steps in the stage.
Use Xrm.Page.data.process.getActivePath to retrieve information about the stages that have been completed, the current active stage, and valid stages available from the current active stage. Examine the steps included in that stage and compare the corresponding form attribute values to determine whether they are completed.
Complete a step
Steps are completed when the corresponding data in the form is entered. You can determine the attribute using the step getAttribute method. This will return the logical name of the attribute. Then use Xrm.Page.getAttribute to retrieve attribute from the Xrm.Page.data.entity.attributes collection and then use the attribute setValue method to set the value.
Detect whether a step is required
Use the step isRequired method to determine if a step is required by the business process flow.
Expand or collapse the business process flow control
Hide the process control
Use Xrm.Page.ui.process.setVisible, you can control whether to display the business process flow control.
Skip to a valid completed stage.
Use Xrm.Page.data.process.setActiveStage to set one of the valid completed stages for the current entity.
Query the process definition including stages not currently visible
Use Xrm.Page.data.process.getActiveProcess to query the definition of the business process flow, including stages that might not be visible because of branching logic in the process.
Events for business process flows
You can interact any event provided by the form with business process flows, but two new events allow you to execute code based on events just for the business process flow control. You can execute code when the active stage of a business process flow changes (OnStageChange event) or when a stage is selected (OnStageSelected event).
The SDK team also provided a couple great samples for the new scripting methods. Check out this sample on how to retrieve information about the enabled processes for an entity and this sample on retrieving information about the stages and steps in the active business process flow path.
Today's post is written by Andrew Monshizadeh, an iOS Developer at Sonoma Partners.
In the previous blog post, we discussed a situation where it would be beneficial to break parts of a Visualforce page and Apex backing into a Visualforce component. As a review, the benefit of Visualforce components is that they make it possible to prevent duplication of code. The less code there is overall, the easier it is to test and maintain.
At the end of the last blog post, the naïve approach to the Case and Case Comment list was implemented using a normal <apex:pageBlockTable> tag in the Visualforce page.
This example is simple. But it isn’t difficult to imagine that a client would want a Visualforce page that included a large number of fields, some for display and some editable, along with validation logic that needs to happen throughout the time the user is on the page, which would need to be done in the Apex controller. Though it would be possible to move the Case Comment based logic to a separate extension controller, this doesn’t solve the problem of truly breaking the code into a reusable chunk. The developer would still need to come back to this page and copy/paste the Visualforce.
Enter Visualforce components.
Visualforce components make it easier to reuse Visualforce and Apex code throughout the entire org. This is because it forces the developer to consider the behavior and content in the component as a stand-alone unit.
The first step to breaking out a component, is determining what exactly should be in the component. It is important at this point to try and determine the smallest set of content and behavior to break out. There is no benefit in carrying around excess baggage. So in this case, the developer would only be interested in the actual table displaying the Case Comments. For this simple example, it is possible to take the original Visualforce and move it into a new component, almost entirely unchanged.
Note that the component has its own backing Apex controller. This simplifies the logic within the component’s Visualforce markup because the backing controller can be developed to fit the needs of the component. Therefore, it is possible to contain just the list of Case Comments with no look ups necessary.
With this component defined, it is now possible to use it in the original Visualforce page in place of the normal table. This also simplifies the page’s controller, so much so in fact, that it is no longer necessary.
Figure 4 - Custom page block table but now in a component
Clearly this simplifies the overall Visualforce page development, and does not impact the user experience. Also, it means that this list of Case Comments may be used anywhere Visualforce is used (and an Account object is available) with a minimum amount of code. Finally, by making this a component, any time a change is made to the component that is reflected everywhere the component is used.
In our next and final Visualforce component post, we will discuss a few advanced uses for Visualforce components.
Like most users of Dynamics CRM 2013, it’s taking me awhile to get used to the new navigation. However, with any software deployment, it takes users time to get used to the new functionality and especially the new look and feel.
It’s hard to remember when CRM 2011 came out (way back almost 4 years ago now) and the introduction of the ribbon. What a crazy concept the ribbon was and how would we ever get used to it? However, after using 2011 over time (and honestly any Microsoft product), the ribbon became second nature. When Microsoft removed the ribbon in 2013, everyone complained it was missing. How would we now get used to not having a ribbon? I believe that over time Dynamics CRM 2013 and 2015 will fall into the same camp as 2011 where users will become comfortable using the new navigation and will have forgotten the ribbon ever existed.
We recently just upgraded our internal CRM deployment to 2015 and I’m forced to get used to the navigation even quicker than originally anticipated. Of course with every new release there are those learning curves and the questions you ask “why did they do it this way?” but the good news is that with Microsoft, they’re listening.
One of the biggest complaints of 2013 is the fact that the Advanced Find was buried and not readily available on the global tool bar like it was in 2011. In some areas of the application you couldn’t even initiate Advanced Find. And those areas where you could, you had to click on the ellipsis to bring down additional contextual menu items to find Advanced Find.
However, the good news is in 2015, Microsoft has listened to initial feedback from users of 2013, and have added the Advanced Find menu back in the global tool bar so that you can always initiate Advanced Find no matter where you are in the application. Enjoy!
Today's guest blogger is Chris LaBadie, a Senior Database Developer at Sonoma Partners
Whenever we work on a data project for a customer the subject of cleaning their client data is always a discussion point. The project could involve a migration from one CRM platform to another, integrating an ERP system into CRM, or even cleaning their data “in place”- but the message is usually the same, “we know we have duplicates in our data, help us clean it up!”
Anybody that has ever tried to track people or companies knows that it can be a huge challenge to avoid duplicate data. When you have multiple users maintaining data, it is very common to introduce duplicate data no matter the de-duplication safeguards your system uses.
Working with people-
• Names can be difficult to track (misspellings, maiden names, nicknames, etc).
• People move/change contact information.
• Even unique fields like address or email address can be shared amongst more than one person.
Working with companies-
• Abbreviations or acronyms in names can present a challenge.
• Companies can have multiple locations.
• Often use different addresses to track billing, shipping, etc.
In our experience, there isn’t a magic bullet to eliminate de-duplication. The best solution is usually a layered approach- use form validation to ensure quality data entry, intelligent system design to store records in an organized manner, and system de-duplication rules to search out potential duplicate data and present to a user records that might match the information they are attempting to enter.
However, a common project for Sonoma Partners is moving a client to a new CRM platform and an important part of migrating data to the new platform is to identify potential duplicate data before it ever reaches the new system. While this may sound like a large effort, it is actually pretty easy thanks to the Fuzzy Grouping functionality built into SQL Server Integration Services (SSIS).
Fuzzy Grouping allows SSIS to inspect a set of data and compare one or more fields in the dataset. Rather than comparing the field data, Fuzzy Grouping will match strings based on their sounds- giving more accurate results based on how a person would hear the string while overcoming misspellings, typos, abbreviations, nicknames, etc. Note, you will need SQL Server Enterprise or SQL Server Developer edition to use Fuzzy Grouping. This example is developed using the Business Intelligence Design Studio (BIDS) in SQL Server 2012.
In this demonstration we will process an Excel file of contacts. This file can be generated from any other system and used in a process like this to identify potential duplicate data before that data is migrated to CRM. The end result of this process is to produce a file containing potential duplicates so they can be reviewed and cleaned up in the source system before data migration.
Fuzzy Grouping evaluates the file of Contacts and compares them based on selected fields. Potentially duplicate records are grouped together and assigned a group number.
After Fuzzy Grouping, the process splits so it can sort the results based on their Fuzzy Grouping group number and count the number of records per group.
Finally, a step to check the group count determines which records are potential dupes- a group count of 1 means the record is unique, anything more than 1 means that group contains 1 or more records that should be reviewed. The potential duplicates are then exported to an Excel file for review.
Configuring Fuzzy Grouping is a pretty straight-forward process, just select the fields you want to compare and set the minimum amount of similarity (roughly a percentage of matching). This process can involve a little bit of trial and error while you fine-tune the Fuzzy Grouping to identify the records that are potential duplicates without letting through any false positives.
Typically we will start with lower minimums and go up until we are seeing the desired results.
When you run the process, you can see how many records it processes and how many records SSIS ultimately decided to export to Excel for review.
When the process is complete, you can view the results in your Excel file. Here you can see the unique record number assigned to the record (KeyIn), group number (KeyOut), overall score (percentage of match to the potential duplicate record), similarities for First Name/Last Name/City (percentage of match for each column), and the Group Count (number of potential duplicates per record group). The highlighted values in the screenshot show some of the values that were compared and demonstrate how Fuzzy Grouping can identify potential duplicates despite common misspellings, nicknames, and partial matches.
In conclusion, Fuzzy Grouping is an easy to use and powerful tool to assist in any data cleanup effort. It is simple to setup, and quickly evaluates large amounts of data. SSIS can provide you with all of the tools to make informed decisions regarding your customer data, your most valuable asset.
Over the holidays, Salesforce posted the Spring ’15 release notes detailing what they’re planning on releasing come mid-February. I’ve poured through them to pull out what I think are the most exciting for both our customers and us.
We talked briefly about this in our Winter ’15 preview post, and with this release it has both become Generally Available and includes several improvements. This feature brings improved duplicate detection and blocking to the core Salesforce platform, and contrary to our preview post this feature does not require an extra license (although it does use Data.com technology). Several key enhancements were made from the Beta release in Winter ’15 including:
- Support for custom objects
- Ability to define cross object rules for duplicates
- Support for picklist values
- APIs and Apex classes added to let developers manage duplicate detection programmatically
There are some limitations to the duplicate detection to be aware of, so as always be sure to read the release notes.
This feature is available in Professional, Enterprise, Performance, Unlimited, and Developer editions.
It would be difficult to create this list and justify leaving out Analytics Cloud. Arguably the biggest announcement to come out of Dreamforce this past year, Analytics Cloud is Salesforce’s take on how to do analytics and reporting in a user and mobile friendly way. It’s built on top of the Salesforce platform so there’s no need to host it yourself, but it does cost an additional fee.
This feature is available in Enterprise, Performance, and Unlimited editions.
This feature is actually a combination of 2 new product offerings from Salesforce: an exchange connector which can sync contacts and events to and from an exchange server and Salesforce, and the Salesforce Side Panel. The exchange connector is the beta portion here, giving administrators the ability to set up a connection between Salesforce and Exchange so that users not using Outlook can still have the records sync between the two. Since this is a server side process, no additional software is needed to be installed on the user’s machines.
This may seem like a silly feature at first, but any business that’s been around for more than a few years will probably have records owned by people who no longer work at the company. Until now, you needed to reassign those records to another user before you could update them. In some cases, especially in integration scenarios, we really just want to update the record no matter who the owner is. With this feature, we can finally do so.
This feature is available in all editions.
With this feature, any record which has a standard address field (Accounts, Contacts, etc) will now display a Google map image of the address if the fields are filled in. Note that Salesforce did send an opt-out notice, and that the feature can always be disabled via the settings menu.
And much more…
Of course, this only scratches the surface of all the improvements made by Salesforce in the upcoming release. If there’s something in particular you are wondering about that we didn’t cover here, feel free to read through the full release notes or contact us and we can help you find what you’re looking for.
Salesforce recently alerted administrators of organizations to an upcoming change to the certificates used in HTTPS. We think that security should always be taken seriously. That being said, it can be frustrating to stay on top of updates, especially if a change breaks your everyday flow. To ensure that as many people as possible see the notification, we’ve posted the body of the notification below.
What is changing?
To maintain alignment with security best practices and the industry-wide shift to use more complex algorithms for HTTPS certificates, Salesforce will be replacing current HTTPS certificates, which are signed with a SHA-1 hash algorithm, to new certificates signed with a SHA-256 hash algorithm. HTTPS certificates are reflected in the browser’s URL bar to indicate a secure connection while accessing secure websites, including Salesforce.
What action do I need to take?
In order for users to continue to have access to Salesforce, you need to ensure your operating systems (OSs), browsers and middleware are capable of accepting HTTPS certificates with SHA-256 hash algorithms.
We are asking all customers to be prepared for this change by:
- April 1, 2015 for Sandboxes
- August 1, 2015 for all Instances
We will begin changing HTTPS certificates in a phased approach shortly after these dates. Exact dates will be published in March 2015.
Is there a quick way to test if I am prepared for this change?
Yes. We have established this test page to quickly check if your OSs, browsers and middleware will accept HTTPS certificates with SHA-256 hash algorithms. We have provided instructions for how to use this test page in this Knowledge Article.
What will happen if my OSs, browsers, and middleware are not capable of accepting these new HTTPS certificates?
If your OSs, browsers, and middleware cannot validate the new HTTPS certificates, your users will not be able to access Salesforce.
Why are you not changing the HTTPS certificates sooner?
The HTTPS certificates that Salesforce uses today are secure. However, it is a best practice to continuously increase the complexity of security encryption protocols and tools. We designed the timeline to give customers time to prepare for this change while maintaining a secure environment.
What if we use middleware that requires us to upload the certificate into the middleware (i.e. locally cached)?
If your organization is running middleware that requires the certificates to be locally cached, you will need to update the cached certificates as a result of this change. To learn more about how this information will be communicated, please join the customer Success Community Collaboration group, Official: Certificate Changes.
Where can I get more information?
We have developed a Knowledge Article to provide additional information. Additionally, you can reach out to Customer Support by logging a case in the Help & Training portal.
Microsoft recently announced new features that have come out with their next version of Microsoft Dynamics CRM 2015 (previously code named Vega). Check out the Dynamics CRM 2015 Release Preview Guide to see what features came with 2015.
Next up for our review are the enhancements being made to Outlook and the Sync Process. One thing to note is that all the enhancements outlined in this blog apply to both the legacy Outlook Sync and new Server Side Sync process introduced with CRM 2013.
Below are the enhancements that are included with CRM 2015. We’ll go into a few of these enhancements in more detail later in this blog.
- Contact Phone Number and Address Sync Improvements
- Sync Outlook Assigned Task (Outlook task assigned to another user that is also in CRM). This is not enabled out of the box and a System Setting needs to be enabled to turn this on
- Sync Appointment Attachments. This is also controlled via a System Setting.
- Configurable Field Level Sync
- Outlook Client
Navigating to Settings –> Administration –> System Settings –> Synchronization will display the dialog of all the organization level settings regarding the Outlook sync process. See below.
In this dialog you have a mix of legacy pre-2015 settings, and a handful of new 2015 settings. The new configuration settings you have at your disposal are:
- Synchronized Fields: This is where an admin can modify what direction fields are synced. This is explained more below.
- Synchronize Appointment Attachments: With 2015, you can enable attachments on appointments to synchronize between Outlook and Dynamics CRM.
- Address Sync: This is explained more in the section below.
- Synchronize Assigned Tasks: An admin can enable if Outlook Tasks that are assigned to another user are tracked in CRM or not.
Contact Phone Number and Address Sync
With CRM 2015, Microsoft has changed the sync process for Contacts. 4 more phone numbers were added to the sync process for a total of 11:
- Assistant’s Phone
- Business Fax
- Business Phone
- Business Phone 2
- Callback Number
- Company Phone
- Home Phone
- Home Phone 2
- Mobile Phone
- Telephone 3
There’s also an organization level System Setting that allows you to indicate if you want to sync either A) just the Outlook Mailing Address, or B) all 3 Outlook Addresses (Business, Home, Other). This setting is available by going to Settings –> Administration –> System Settings (shown above).
Configurable Field Level Sync
One of the biggest questions we’re asked over and over with our clients is what fields are synchronized between Outlook and Dynamics CRM. There are a few sites out there that go into detail on what fields are synchronized, but nothing within the application provided by Microsoft. They also don’t easily indicate which Outlook fields synchronize to which CRM fields, the direction of the sync, and the ability to turn off that sync (in other words, all fields synchronized all the time).
Now with Dynamics CRM 2015, you can navigate to Settings –> Administration –> System Settings –> Synchronization –> Synchronized Fields. From this location, you can see the mapping between Outlook fields and CRM fields and the direction that the sync is currently configured for.
For each field you can modify the sync direction so that it syncs both ways, sync one way, or don’t sync at all. This is currently an Organization level setting that’s setup in the Settings area of CRM and one improvement that I can see here is making this a user setting so that each user can have individual unique sync experiences if for some reason they don’t want to share information about Contacts that are in their Outlook and also tracked within CRM. However, for the current release of 2015, individual users can at least view the sync directions that their administrator setup by navigating to their Personal Options –> Synchronization –> Synchronized Fields
There are a couple quick use cases that come to mind that I know most customers would be ecstatic to get their hands on:
- Private Notes: Turn off the sync process on the Outlook Notes field. Therefore users can add Notes within Outlook and they won’t flow to CRM for everyone to see. They can keep their own personal notes locally in Outlook.
- Read Only CRM Data: Set the sync direction on the desired read only fields to go from CRM to Outlook only, meaning updates in Outlook will not update CRM, and CRM will overwrite Outlook changes.
Another resource on this subject is an article that Microsoft recently published. While having this in the application is useful, this link also provides more details for administrators.
Outlook Client Enhancements
There have been changes to the Outlook Client itself in addition to the sync changes.
First off Microsoft has now added OAuth support to the Outlook Client. This enables multi-factor authorization to the Outlook client and brings consistency across CRM clients (web and Outlook).
Microsoft has also cut the clutter out of configuring the Outlook client. Users simply need to provide the Organization URL to get up and running as fast as possible. See below for what the configuration process looks in Dynamics 2013, and how much easier it is in 2015.
Also, in order to help troubleshooting issues between Client and Server, Dynamics CRM 2015 now automatically detects compatibility issues between the Client and Server. A notification is sent to the user if a compatibility issue is detected.
Finally, another troubleshooting addition made by Microsoft is when errors are detected, a “Resolve This Issue” dynamic help link will appear. This link will be dynamic and will search a server side database of articles that will route customers to the right resolution for their issue.
Upgrade Experience and Supportability
This topic isn’t really an enhancement, but goes into details on moving to the Dynamics CRM 2015 Outlook client, and what versions are supported.
In order to upgrade to the 2015 Outlook client, you must be on Outlook 2010 or higher (support for Office 2007 is being dropped). Microsoft is also dropping support for:
- IE 8, IE 9
- Windows Vista
- Windows Server 2008 Remote Desktop Services
- Windows Server 2008 R2 Remote Desktop Services
The Outlook Client must be in “Online Mode” for the upgrade to succeed, and Microsoft is allowing all 2013 Outlook Client versions to upgrade to the 2015 Outlook Client. Also, users will be able to continue to use the 2013 Outlook Client if they deploy the 2015 server. However, they’ll only be able to use it in “Online Mode” (i.e., no offline capabilities will be supported).
The recommended process for upgrading your Outlook Client is the following. This process will ensure users are able to continue to use their Outlook Clients during your server upgrade to Dynamics 2015.
- Upgrade all Outlook Clients to 2013
- Upgrade your server to 2015
- Upgrade all Outlook Clients to 2015
We hope you’ll find that these improvements will add more configurability and robust functionality to the Outlook Client. I can see some future improvements Microsoft may want to add in with the sync process (allowing administrators to add/remove/edit what Outlook fields sync to what CRM fields including the ability to sync to custom fields), but it’s good to see Microsoft is continuing to go down the path of putting more configurability options in the hands of administrators, and removing any hard coded logic.
Good luck with your 2015 upgrade, and with all upgrades, plan…test…plan…and test some more!!