As many are aware, the Dynamics CRM Online 2015 Update 1 has been live for a bit of time now. With it come a lot of shiny brand new features for everyone to play with, of which we’ve been blogging about on our site for a bit of time now.
However, with all great new toys, there are usually some pitfalls to be aware of and avoid. And this release doesn’t fall short of that classification, as there is a potential headache that most customers and partners should be aware of and plan for.
Microsoft posted on their blog some good detail about some performance improvements that were made to form load times. This is great as I’ve heard from multiple customers (and experienced) the slow loading forms that seem to have popped up when CRM 2013 released with its new UI scheme.
As seen in the image below, the new rendering forms of Dynamics CRM Online 2015 Update 1 drastically improve load times of forms.
From Microsoft’s blog post, you can see details of what they changed to get this improved performance. However, with those changes comes the risk of unsupported scripts now failing. Some examples of where scripts could fail are:
- DOM manipulations
- Accessing internal iFrame URLs
- Accessing unsupported APIs
- Other windows related assumptions
However, the good news is that there’s a plan in place that you should follow to resolve these issues.
- First off, make sure that you test your environment thoroughly in a sandbox instance before updating your production instance to identify any potential issues.
- If you find something that is broken, you can temporarily turn off the new form rendering by going to your System Settings, and setting the “Use legacy form rendering” option to Yes. Note: This option to use the legacy settings is most likely going away with the next major release, so please plan on fixing your broken scripts immediately to avoid issues in the near future.
- You can also download the CRM 2015 Custom Code Validation Tool from this link, and run it on your environment to identify the usage of any deprecated API’s as well as any usage of unsupported API’s.
Moral of the story, be aware, be prepared, and have a plan. You definitely don’t want to be caught by surprise in production when you’re getting random errors loading forms. Good luck!
In part 1 of this series, we talked about what Invocable Actions are, and the problems they are attempting to address. In part 2, we looked at how to discover what actions are available to you, as well as what the inputs and outputs for each are. And in part 3, we looked at how to use the actions in your organization. In this fourth and final part of the series, we will look at how to extend your organization by creating custom actions in Apex.
Creating our custom action
To begin creating our custom action, we need to first understand the @InvocableMethod and @InvocableVariable annotations. Combined, these let us define a method which can (optionally) take in a collection of objects (variables), do some work with them, and (optionally) return a collection of objects (variables).
The @InvocableMethod annotation defines the entry point for our custom action, and there may only be 1 per class file. There are also a bunch of other restrictions placed on this method, such as it having to be static and either public or global. Be sure to read the documentation for a full list of requirements.
The @InvocableVariable annotation is used to decorate the input and output types, denoting what metadata should be published to the outside world.
Both of these annotations have label and description properties, which are published in the metadata to make the method, its inputs, and its outputs more human friendly.
For our example, assume we have the following code which is our custom action:
This class demonstrates a few important notes about custom invocable actions:
- If they have inputs, they always take in a collection of inputs, encouraging batch processing.
- If they return values, they always return a collection of values.
- The inputs and outputs can be complex types, but the members decorated with @InvocableVariable must be either simple types (strings, numbers, booleans, IDs, etc.) or concrete sObject types (Accounts, Contacts, custom object types, etc.)
Once we have saved the code to Salesforce, we can explore the metadata that is published about it in the REST endpoint. Since we created a custom action using apex, our starting point is:
Here you can see the label that we defined in the @InvocableMethod annotation is being published along with the name of the class. We can use the name property to find out more about our custom action in the same way we did in Part 2 with the Chatter action:
Here we can see the full metadata for our action, including the inputs, outputs, and the labels and descriptions for each that we provided in the code. This makes it convenient for us to document our custom actions, since all of the information comes from one place that is regularly maintained. This also follows the same format as the standard actions, so we can use the techniques from Part 3 to craft a request to send to Salesforce, and use our custom action to perform work.
While creating custom actions with a standardized input/output format is nice, what really makes Invocable Actions worth investing in is their potential for reuse. In our post on invoking apex from lightning processes we show you how to use custom actions in the lightning process builder, giving non-programmers access to more functionality at a faster pace than before.
In this 4 part series, we talked about why Invocable Actions were introduced, how to find what actions you have in your organization, how to use them and how to create custom actions of your own. We hope that you have found this series to be interesting and useful. If you have any questions or thoughts, feel free to leave us a comment below or contact us.
In part 1 of this series, we talked about what Invocable Actions are, and the problems they are attempting to address. In part 2, we looked at how to discover what actions you have available to you, as well as what the inputs and outputs for each are. In this post, we’ll look at how to use that information to perform a call to Salesforce.
Posting to Chatter
For our example, let’s post a new message to chatter. We can view the expected inputs and outputs by sending a GET request to
For our example, what we want to do is post a new message to chatter saying “It worked!” in the default public group:
We can accomplish this by filling in the various inputs and sending a POST request to the same url:
After sending the request, we can see a success response returned with the ID of the feed item that was created, as well as the chatter post in the group feed.
This sample shows a few important things:
- Actions always take a list of arguments, allowing you to perform the same action on multiple sets of arguments at the same time. This reduces the number of calls you need to make to the server.
- Inputs, like the outputs, follow the JSON format.
- You input body will always start with an “inputs” property which is an array of the argument JSON objects. The objects inside this array are what change from one action to the next.
- The response is always a JSON array. The objects inside this array follow the format described in the actions output metadata.
With these conventions in place for all invocable actions, it becomes easier to figure out how to call a web service and accomplish work using the Salesforce platform.
Sending HEAD Requests
Up until now, we have only used GET requests to request the metadata of an action, and POST requests to send data to the server. The Force.com Actions Developer’s Guide also lists HEAD as being an available option. When a HEAD request is sent to an action’s endpoint, Salesforce returns a 200 OK response if the action is available in the current organization, and a 404 otherwise. This can be useful for quickly checking if:
- A known action has been installed in the target organization
- The action is available on the given API number
- The currently logged in user has access to the action
In this post we learned how to use the metadata we discovered to make a call to Salesforce and accomplish an action. In the 4th and final post of this series, we will write our own custom action using the @InvocableMethod annotation to extend the platform beyond what is possible through configuration.
We are excited to announce the release of another free community solution, Dynamics CRM QuickNav 2015. QuickNav provides for easier way for users to navigate the sitemap in Dynamics CRM 2015.
The recently launched Microsoft Dynamics CRM Spring 2015 Release provides a much needed usability facelift to the main navigation as shown below.
However, since the Spring 2015 Release is for CRM Online only, on-premise customers will need to wait till the fall before they can use this new feature. Enter QuickNav!
QuickNav is a simple managed solution that reads your deployment’s sitemap settings and displays them in an easy to click list. Some features of QuickNav include:
- Easily find sitemap items with the Quick Find search, including native settings links
- Displays and finds all subareas of Settings page – this feature is great for system administrators!
- Keeps track of your most visited and recently visited links
- Works with both CRM 2015 on-premise and CRM Online deployments
For our Dynamics deployment, I set the QuickNav as my home page, allowing me to quickly access the navigation with one click on the home icon. Download QuickNav and try it out on your CRM 2015 deployments today!
With the release of CRM Online Spring 2015 Update, Microsoft provided a long awaited feature for developers that we are really excited about. That feature is a built-in Plug-In Trace Log that allows developers to utilize the existing ITracingService and provide a way to see any traces without requiring an error to occur to see the trace.
Here’s how it works:
- First we need to enable the Plug-In Trace Log within the System Settings under the Customization tab. You can choose to log only Exceptions or both Exceptions and Traces.
- Next, utilize the ITracingService to write out a trace and/or throw an Exception within a plug-in
- Next, register your plug-in on the desired step as normal. In my example I am registering it on Create of an Account
- When I attempt to Create an Account record then I receive an error message with the exception that I wrote in the plug-in
- Now Navigate to the new link in Settings –> Plug-In Trace Log
- You should see a grid of all the Plug-In Trace Logs per plug-in execution
- Open up the trace record and you will see the details of any traces and exceptions that occurred with the plug-in. It also provides the duration of the plug-in execution which will definitely come in handy for performance testing.
As you can see, this feature will come in handy and should eliminate the need to use a custom entity to store any log entries. It also eliminates the need to require users to click the “Download Log” button on the error dialog in order to send the log file when an error occurs.
In part 1 of this series, we talked about what Invocable Actions are, and the problems they are attempting to address. In this part, we’ll talk about how to go about discovering the Invocable Actions already available in your organization.
Viewing your services
To view your services, you will need a tool that can issue REST calls against your organization as well as API access to do so. The easiest tool to use is the Workbench at Developerforce (https://workbench.developerforce.com). After signing in, navigate to Utilities > REST Explorer.
On the following page, the base URL for your organization’s REST endpoint will be prefilled for you. If you execute a GET request against this endpoint, Salesforce will return a series of endpoint that can be used to describe various metadata about your organization. Today, we’re interested in the ‘actions’ endpoint.
If you issue a GET request to the actions endpoint, you will see your actions grouped in to two broad categories: standard (actions that come out of the box with Salesforce) and custom (any custom invocable actions you have created in your organization).
Note that there may be custom actions listed for your organization even if you haven’t written any code. Salesforce also automatically exposes things like email alerts, flows and quick actions for you so that code can be developed against them if desired.
Viewing your standard actions
We can view the standard actions provided by Salesforce by navigating to the
endpoint. When a GET request is sent to this endpoint, Salesforce returns a JSON blob describing the services available, as well as some high level metadata about each.
Here you can see a human friendly label, as well as the API name of the action (name field) and they type of action it is (type field). If we wanted to know the details about a particular action (like the Post to Chatter action), we can send a GET request to
In this response, we now get the details for what the inputs are to the action, and what it will return to us. It also gives us detailed information around the types of the arguments, as well as valid values if the arguments are picklists, which are required, maximum length, etc. With this information, clients can enforce valid data is entered before ever sending a request to Salesforce, reducing API and network usage.
Viewing your custom actions
We can view any custom actions in your organization by following the same process, but using the
endpoint instead of the standard endpoint. In the case of custom actions, the results are grouped by the type of action as well:
You can drill further down to see the various actions under each type, and then follow the format from the standard actions to get the specific details for each one.
As you can see, discoverability is straight forward and rich using the REST endpoints provided by Salesforce. While this portion of the API is not new with Spring ’15, understanding how to use it and read the results is key when we look at custom Invocable Actions in a following post.
Microsoft recently announced the General Availability of the CRM Online Spring Release ‘15 and we wanted to share yet another one of the new features that has been rolled out to CRM Online. This post will cover the new Folder Level Tracking feature that CRM Online users should start seeing, and CRM On Prem users should hopefully see in the near future.
What is it?
Folder Level Tracking is another way for users to track emails in Dynamics CRM from Exchange. With Folder Level Tracking, you don’t need to have the CRM Outlook Client installed. This means that Folder Level Tracking will work with native mobile apps. For example, if you use a Windows Phone, you can move emails from Exchange to CRM by directly using your Windows phone and we’ll describe how below.
How does it work? Well there are two main scenarios that Folder Level Tracking supports:
- Quick Track:
- This is the scenario where you want emails to quickly be tracked in CRM without setting a regarding.
- This is equivalent of clicking the “Track” button alone in the current CRM Outlook Client
- Users can move emails to a specific folder (e.g., “Track in CRM”) and all emails moved to that folder will be tracked in CRM automatically
- Set Regarding:
- This scenario is where your emails will be tracked in CRM, and be regarding a specific record in CRM
- This is equivalent of clicking the “Set Regarding” button in the current CRM Outlook Client
How do you set it up?
Folder Level Tracking has a few requirements for it to work. First there are system level settings that need to be enabled.
- First off, Server Side Synchronization needs to be enabled and configured within CRM System Settings
- Also, Folder Level Tracking needs to be enabled within CRM System Settings
- The User’s Mailbox in CRM also needs to be setup and enabled
Now the users themselves also have to go within their Personal Options –> Emails –> Configure Folder Tracking Rules. From here they can select the Exchange Folder, and then the CRM Record (optional) they want to track the emails against.
As you can see from above and as stated earlier, these are user specific configuration rules so each user can have their own synchronization setup. That’s it! Pretty simple right?
What does this mean for me:
This is a new powerful option to track emails. The beauty of this is that you don’t need to have a separate client installed, but it’ll work with any native client you’ve been using for emails. This is available for ALL mail apps on ALL devices.
There are a few tips we recommend when using this option.
- You can setup Exchange rules to move emails to specific folders (including the generic “Track in CRM”) to have the emails automatically track in CRM based on your Folder Level Tracking configuration rules
- As stated above, you can move emails using your native mail clients (Windows Phone, iPhone, iPad, etc.) and have the Folder Level Tracking rules apply and create the email in CRM
A few notes that you should be aware of:
- The mapping between the Exchange Folder and CRM Record are using their respective ID’s, so you can change the name of the Folder or Record, and the tracking will still work.
- If an email is already tracked, and you remove it from the Exchange folder, it WILL NOT be removed from CRM. It will remain to be tracked.
- Removing a rule WILL NOT remove / delete the emails from CRM that were tracked because of it
- There is SDK support to manage the configuration rules (create, retrieve, modify)
- You can always specify a regarding for your rule at a later time if you don’t set it up upon create
- The Folder list in the Rule UI is updated periodically when the mailbox is synced via Server Side Sync and the last sync displayed on the mapping dialog
I hope you’re as excited for this new feature as I am. I’ve been a part of many mobile projects where the CRM Outlook Client isn’t installed (can’t be installed), yet the client wants to send an email from the device and have it tracked in CRM. To date there’s been no simple way to use the native mail client, and have those emails tracked, but Folder Level Tracking should solve that problem. Enjoy!
When writing custom code on the Salesforce platform, it’s not unusual to need to read the debug logs to understand why a piece of functionality isn’t working as expected. Unfortunately, the debug logs are flat files, which can make deciphering what chunk of functionality started another chunk challenging - especially as the debug logs grow large. To help tackle this problem, we’re introducing a new tool: Tree Log. This tool can parse the log files and display a tree view of your logs, helping you understand what cause what to run, and the order in which it executed.
Accessing Tree Log
Tree Log is entirely web based, so there is no need for installing extra software or browser plugins. You can access the app by navigating to http://tree-log.herokuapp.com. On the home page, you can either upload a file you have saved from Salesforce, or paste the contents of any log in to the page.
Once you submit the form or upload the file, the log is parsed and a tree view is displayed. You can then click on the various parts of the tree to see the logs associated with just that branch.
We hope this tool helps you debug your applications more quickly, and makes understanding the dependencies that caused your functionality to run easier. If you have any problems with the application, please leave us a comment below, or tweet at me @nadrees.
"We can do this in a better way."
That's the conclusion that M. Holland came to when they recognized the need for a CRM solution. They pinpointed deficiencies in their business processes and looked to CRM to take them from -1 to 0. But what started as a CRM implementation project evolved into so much more the moment they realized that by changing nothing, they could change everything. They didn't need to invent new processes or technologies. They needed to alter the delivery of the information they already had and make the functions they always had to do more accessible. To get from 0 to 1, and a place where they had a competitive advantage, they needed a mobile application.
Take it to the field
In the early stages of their CRM project, M. Holland team members took our UX architects into the field to collect essential observational data. They went on ride alongs to watch how people actually did their jobs, instead of listening to them explain how they thought they did their jobs. We found that what was supposedly being met on paper wasn't being met within the context of modern mobility. And with that, the conversation headed in a new direction - towards the creation of a mobile app.
No wheel to reinvent
The mobile app discussion was far from revolutionary. Mobilizing your business doesn't require you to make big changes in relation to what you do or how you do it; it requires you to change how the information and processes you have are communicated and accessed. Once in the field, M. Holland recognized that their people were trapped in the paradigm of their every day. Their sales force was frustrated with their existing tools and felt stuck. Getting information from various locations and drives in their laptop was a painful task. What their team needed was a fresh perspective.
IT to the rescue
It took a technology person to uncover that fresh perspective. Through the participation of junior-level UX activities, M. Holland's IT team was able to understand the tactical flow of events that the field team completed in the real world. Understanding the back and forth of activities and data in a dynamic way allowed them to see things differently, and beg the question: what if we did all of the things we're doing but in a mobile-centric way?
Enter Sonoma Partners
M. Holland’s IT team laid the framework that allowed our UX team to create the mobile solution that they were looking for. Take a tour of two of the app screens below:
Account – Canadian + Ship To
Take a look at the landing page for an account in the phone app. We put the absolute key information, specifically information that a user might need on their phone, on the surface as soon as an account is located.
Here you can see the account name and number along with the ship-to details. This is useful for the common case of speaking with M. Holland Customer Service on the phone. If a shipment is delayed, a rep will need this info and it’s important that it’s easily accessible.
The Alerts + Tasks section clearly shows any outstanding work items related to this account. The contacts section allows the rep to tap in and see all contacts at this account. Since we know a rep typically deals with one primary point of contact at a given account, we created a special display of that person’s info on the front page. We then give one-tap access to the rep so they can quickly email or call that individual.
Breaking the task list into “Needs my attention” and “Awaiting others” is a relatively simple concept from a CRM customization perspective. But in a mobile app, it is a very big deal. This function allows the app to replace excessive amounts of emails back and forth between sales reps and product folks. With one tap they can answer two questions:
- What do I need to work on?
- What’s the status of XYZ I fired off?
Finding the answer to both of these questions used to require annoying searches through an overfilled inbox. With the app, problem solved.
A solution that has:
- Improved customer experience, leading to more opportunities and growth
- Pushed the technology team to be engaged in the business
- Increased credibility of the organization in the eyes of their customers
- Capitalized on the momentum of mobility to better serve their field team
Neil Goodrich, CIO of M. Holland Company will be presenting How Changing Nothing Can Change Everything on Tuesday, May 12, 2015 at 3:30 pm at appsworld North America 2015. Come learn more about how M.Holland achieved their mobility goals and how the IT team played a central role in creating that vision.
When building custom applications on top of the Salesforce platform, it’s not unusual to need web services beyond those that are provided out of the box. The reasons for needing them are many, but generally consist of one (or more) of the following core reasons:
- Wanting transactional support when creating records of different types
- Consolidating business logic in one platform
- Exposing a simpler API to the outside world, obfuscating details about the Salesforce platform
- Reusing the platform instead of creating yet another piece of infrastructure to maintain
Regardless of the reason to build a custom web service, Salesforce has supported two primary ways of creating them: REST based and SOAP based. Both have their advantages, and depending on which you wanted, you would use either the @RestResource annotation or the WebService keyword. With Spring ’15, a third way to expose apex via web services has been introduced: custom Invocable Actions via the @InvocableMethod annotation.
Yet another way to write web services?
To understand why this annotation was added, we need to first look at the limitations of REST and SOAP in general.
REST is very lightweight, using just the native HTTP protocol and some conventions to transfer data back and forth between client and server. While this makes REST a good choice for many applications, one of its main drawbacks is a lack of programmatic discoverability. Discoverability is key for widely used APIs as it helps the consumers understand what the service is expecting in order to function correctly.
In contrast, SOAP provides strong discoverability in the form of WSDLs, which detail what the arguments are, what the return values are, and the valid data types of everything involved. With this amount of metadata available, tools in some languages (notably .NET and Java) have been developed that will generate the code necessary for a developer to use the web service, reducing the amount of time it takes to write applications against them. However, SOAP is relatively heavyweight both in terms of its complexity and actual data transfers, potentially resulting in slower performance on underpowered devices (like mobile phones) and making debugging it a daunting task.
The ideal scenario is to have something that is as lightweight as possible (a la REST) but still discoverable enough that tools can be built against it to assist developers (a la SOAP). On the Salesforce platform, this is Invocable Actions.
Bridging the gap between SOAP and REST
Invocable Actions attempt to provide the best of both worlds through a combination of metadata provided by the programmer (via annotation arguments) and reflection on the code itself, while utilizing JSON for the underlying data transfers to keep things as lightweight as possible. When asked for the description of the metadata, Salesforce returns the name of the method, its arguments names, and metadata about the arguments (such as argument types, minimum occurrences, maximum occurrences), to the caller, allowing it to potentially generate code and/or UI components to satisfy the requirements.
As an added bonus, apex decorated with the @InvocableMethod annotation is also available to be used in the Lightning Process Builder, promoting reuse of your code even by non-developers.
In the following posts in this series, we’ll look at how to discover the metadata for your organization, how to use these web services, how to write and test your own custom services, and how the metadata that is displayed by Salesforce is determined.
Microsoft recently announced the CRM Online Spring Release ‘15 and subsequently lifted the NDA around the release and therefore it’s time to start posting about all the great new features coming!
This post will cover the new Immersive Excel feature that Microsoft is rolling out.
What is it?
Immersive Excel is Microsoft’s new way to have a richer Microsoft Excel experience directly in Dynamics CRM. You’re no longer required to export your data to Excel to be able to perform more complex analysis on it (though this functionality still remains). You can now perform this analysis directly within Dynamics CRM.
What can it do?:
So what can the new Immersive Excel feature within Dynamics CRM do? How close to actual Excel do I get when I use it? Well the answer is that Immersive Excel is actually using Excel Online from within the CRM browser window. Therefore anything you can do with Excel Online, you can do with Immersive Excel.
This includes the ability to work with Excel Formulas directly from your list of CRM data, without leaving CRM. You can calculate what the Commission you could make for your Opportunities, by multiplying the revenue by 10%, if the probability is at least 90%.
You can make updates to records which honor field validation (e.g., you cannot enter a string into a date field, you can only select from the available option set values, min and max values, etc.), and then click on Save Changes to CRM. Or you can simply return back to the CRM list without saving your changes. Immersive Excel allows you to change multiple records quickly acting like an editable grid. However, you must click the button to save the changes before the records are updated.
You currently cannot do perform a Save As to save an Excel Doc (due to technical limitations) but you can copy/paste from the embedded Immersive Excel page to another Excel document. Hopefully this will be fixed in a future release.
In order to make use of this new functionality, the following requirements must be met:
- CRM Online (currently we are unaware of any plans to bring this to OnPrem)
- Separate O365 License required (Online version of Office)
- Export to Excel Security Role Privilege
- Available in the Web Client only (not available for the phone, tablet, or Outlook clients yet)
Miscellaneous and Summary:
Immersive Excel is a neat new tool that will provide CRM users with an additional option to perform some more ad-hoc quick queries, reports, dashboards to analyze data on the fly.
Note that this functionality is recommended purely for “on the fly” analytics, and not for someone to save the Excel file locally. Use Export to Excel for that functionality.
After 5 minutes, the file is regenerated per view per user. There is an indicator in the top right of the page shows when the file was generated. Take note of this time as Microsoft doesn’t want to bombard the servers with constant regeneration, but they also don’t want the data to become stale. Therefore if you’re using this functionality to make changes to records, remember to save early and often to make sure none of your changes are lost.
Also note that the import of the data from Excel Online will take time. A data import async job is kicked off to perform this functionality that you can monitor to see when it completes.
I hope you’re as excited about this functionality as we are, and hope you’re able to get your hands on it soon!
Microsoft recently announced the CRM Online Spring Release ‘15 and subsequently lifted the NDA around the release and therefore it’s time to start posting about all the great new features coming!
This post will cover the new OneNote Integration feature that Microsoft is rolling out.
How it Works
Now with the new release, there will be a new OneNote tab that’s part of the activity Social Pane (posts / activities / notes / OneNote). This functionality isn’t limited to only the web, but is also available on the Phone and Tablet clients as well.
A few key features and benefits of the OneNote integrate with CRM are:
- You can take photos, record voice, manage to-dos, preserve HTML & hyperlinks, use handwriting, have tables, embedded Excel docs, etc.
- Uses the native CRM Security Model for access
- Allows version history
- When performing a search, it actually searches the content of the note, and not just the title like traditional notes
- Stores notes in SharePoint not in CRM Database
- Each record in CRM has a dedicated notebook in SharePoint
- SharePoint Notebook name = CRM Record name
- Each notebook can have multiple sections with multiple pages
- All users share the same notebook
- Web Client: opens OneNote Online in a separate tab
- Tablet Client in Windows: opens OneNote app in the side-by-side experience with CRM
- Phone Client: opens OneNote App
- Notebook can be auto created when OneNote tab clicked (in the Web Client only)
- Navigate to OneNote to add new notes
There are some best practices that you should be aware of if you’re interested in using the OneNote integration with CRM.
- Pin notes on your device.
- Use side-by-side experience for windows
- Take notes quickly using Quick Notes and move to page later
- Close notebook when not using it to save OneNote performance and search results
Setup and Requirements
The OneNote integration currently is only available for CRM Online. Also, you must have the SharePoint integration enabled as the OneNote notebooks are stored in SharePoint.
You need to enable the SharePoint integration (Document Management) for the specific entities that you’re interested in storing OneNote documents for. Once you enable this on the entity definition, you then have to go into the OneNote Integration settings area, and enable OneNote for those entities. The list of entities that appear in the OneNote Integration settings are those entities which have SharePoint enabled.
Note that the OneNote integration can also be enabled from the entity itself once Document Management is enabled. So you can go to a global area to see all the entities where OneNote is enabled, or you can do it from a single specific entity.
I recently ran across something odd the other day that took a bit of investigation to figure out: if you have record types enabled for an object, and you also have chatter enabled, when you go to delete an old record type you no longer need you may not be able to. Let’s say I have an ‘Original’ record type defined for my Account object that I want to remove. To remove it I would go to Setup > Customize > Accounts > Record Types > Edit Original > Deactivate. Once deactivated, I could delete it. However, if Original was the first record type I had created and I set it to the default record type for all profiles before enabling chatter, I would receive the “This record type cannot be deactivated because the following profiles use this record type as default.” error message:
Normally this would be no problem, as we could just go in to the offending profile (Marketing User for example), scroll to the Record Type Settings section and click Edit next to the Account record type to choose a new default:
However, if we try to do this with one of the Chatter External or Chatter Free profiles, we find there is no record type section!
This is unfortunate, since it means there is no native way to change the default record type for these profiles.
Working around the problem
Warning: the work around below is undocumented and technically unsupported, use at your own risk.
After doing a bit of searching, I found this idea on the IdeaExchange which deals with this shortcoming specifically. (You should up vote it so we don’t have to do work arounds anymore). In the same idea, someone else posted a work around which involves manipulating the URL to be taken to a native page which will let you set the default record type. The url has the form:
The instance is the instance your organization is on (na1, eu1, cs1, etc.) and you can get it from the url in your bar:
If you have My Domain enabled, you can use your domain name in its place.
The profile id is the id of the profile you want to edit the default record type for. You can get this by navigating to the details of the profile in the setup menu and grabbing the ID from the url:
This part is a little trickier, and how it works depends on if you’re using a native object or a custom one.
For native objects, object name is just the API name of the object. For example, for Accounts it would just be Account.
For custom objects, object name is actually the id of the custom object. You can get this by going to the setup details for the object (Setup > Create > Objects > (your object)) and grabbing the id from the URL:
Once you have constructed the url, enter it in to your browser to be taken to the same type of page as you get for the other profiles:
Switch the record types around and set the default as needed, then click save. Repeat as necessary for any other profiles you cannot edit natively.
Once this is done, you will be able to disable and delete the offending record type.
If you have any questions feel free to leave us a comment below or contact us.
Microsoft recently announced the CRM Online Spring Release ‘15 and subsequently lifted the NDA around the release and therefore it’s time to start posting about all the great new features coming!
This post will cover the new Office Groups Integration feature that Microsoft is rolling out.
First off let’s discuss what Office Groups are. Office Groups are a new space to collaborate with a group of O365 users. These don’t have to be CRM Users, but instead just users of O365.
With Office Groups, you easily indicate what content from different Office products should be shared with other O365 users. This can be content from Outlook, OneNote, OneDrive.
To be more specific, the following content can be shared from these Office products:
- Calendar (Outlook Appointments)
- Conversations (Outlook Emails)
- OneNote: Notebooks
- OneDrive: Documents
Now that we know the basics of what Office Groups are, how does it integrate with Dynamics CRM?
For each CRM record identified to have an Office Group created, an Office Group will be created behind the scenes for that record. The CRM Record Name will become the Office Group Name.
Then, on the CRM record form itself, there will be a tab “Items Shared with Group”
This tab will allow you to collaborate with non-CRM users who are O365 users. On this tab you’ll be able to:
- See across the various office products (Outlook, OneNote, etc.) items shared to the specific office group
- See Yammer like conversations for emails
- For Opps Only, adding people to the Sales Team will automatically add the person to the O365 group
Currently this is a solution that’s available on the O365 Admin portal. In order to take advantage of this functionality, you’ll need to download and import this solution to your CRM organization.
Once the solution is imported, it’s as simple as typing in the entity name that you want to enable Office Groups for, and then also indicate if you want an Office Group automatically created for new records that are created of that entity type.
A new Security Role is provided in the solution that you’ll have to assign out to your users to take part in this new functionality. This role provides access to create/view the Office Group entities that are provided in the solution.
Currently this functionality is only available on CRM Online and Office Online. I can see down the road this being applied to CRM On Prem, and Office On Prem so that users could have a hybrid of CRM and Office solutions and still take advantage of this functionality.
Also, the functionality of Office Group emails on the record form are very similar to Yammer. There may be an opportunity here for the Yammer and Office Group teams to talk and consolidate products.
Finally, the functionality to have people automatically added to the O365 group from the Opportunity Sales Team, would be beneficial to have extended to other entities and not just Opportunities
So when would you use this new Office Group functionality? When you need widespread collaboration for people that are internal that don’t have access to CRM with those that do have access to CRM
We at Sonoma believe user experience is one of the key drivers towards user adoptions of your CRM platform. We also understand the pain that users face when a system they expect to be working suddenly becomes unavailable or unresponsive. Because of this, when we recently received communication from Salesforce about a new login pool coming to Japan, we felt it important to do our part to help the message reach as many people as possible. We are glad that Salesforce is continuing to invest in their infrastructure, improving resiliency, and we also want to help ensure that everyone is able to make changes as needed to prevent any down time.
Below is the body of the communication sent by Salesforce, please read it carefully to determine if any action needs to be taken in your organization. If you have any questions, always feel free to contact us and we can help determine your best course of action.
At Salesforce, trust is our top priority and we’re working to improve your login performance, regardless of which instance you’re logging in from.
Last year, we further improved the resiliency of our infrastructure by adding additional login pools to our midwest and east coast data centers. On April 11, 2015, we are adding a login pool in Tokyo, so if your end users are accessing Salesforce from the APAC region, they will authenticate via the new login pool in Tokyo, thus reducing the time it takes to login.
In order to take advantage of this improvement to the login experience, please take the actions below to prepare your organization.
If you do not take action, your end users may not be able to log in, and your inbound integrations may stop working starting on April 11, 2015.
What does this mean to me?
Login pools only affect you if both of the following apply:
1. Your end users or inbound traffic integrations use login.salesforce.com to access your production instance.
2. Your IT department has set up your corporate network settings (ie. proxy settings or firewalls, etc.) to restrict access to only certain Salesforce data centers or instances (ie. whitelisting certain IP addresses or ranges, hard-coding references to your specific instance, etc). Please note: This is not done in the Salesforce app, but in your corporate IT network settings.
If both of the above criteria do not apply to you, then you do not need to take action to prepare for the additional login pools.
What action do I need to take?
If your IT department has set up your corporate network settings to restrict access to only certain Salesforce data centers or instances, you will need to update your corporate network settings to allow access to all Salesforce data centers.
If your IT department currently restricts access by certain IP addresses or ranges, please refer them to the the full list of Salesforce IP ranges available in the What Saleforce IP ranges should I whitelist? Knowledge article.* If you would like to confirm that your corporate network settings are prepared for login pools, please see the How to Prepare for Additional Login Pools Knowledge article referenced below. Please note: You will need to allow access to all of the ranges for every data center, regardless of where your instance resides.
*For security purposes, you will need to login with your Salesforce credentials to view the list of IP ranges.
What if I do not update my IP ranges to include all Salesforce data centers?
If you do not update your corporate network settings to allow access to all Salesforce data centers, and your end users and integrations reference login.salesforce.com, your end users may not be able to log in and your inbound integrations may stop working starting on April 11, 2015.
When is this change taking effect?
We’re adding a login pool to the Tokyo data center on April 11, 2015. Please check trust.salesforce.com/trust/maintenance/ for further updates.
What are login pools?
Login pools process all login requests when end users or inbound-traffic integrations attempt to access the Salesforce app. Once enabled, end users and integrations will be sent to one of our login pools across our data centers, which then verifies credentials and forwards to the appropriate instance.
Why am I receiving this information?
As an administrator of a Salesforce org, if you have end users with multi-national internet entry points, then you should whitelist all IP ranges. This includes remote offices and end users trying to access Salesforce while traveling. (For example, if you have an employee traveling to the APAC region and you do not whitelist the IP ranges as outlined in the What Saleforce IP ranges should I whitelist? Knowledge article, the employee would not be able to log in as our login pools would not be able to process their authentication due to whitelist blocking.)
Where do I get more information?
To help answer your questions, we have prepared this How to Prepare for Additional Login Pools Knowledge article & FAQs.
To learn more about this maintenance and how it will impact you, watch this recording of the New Tokyo login pools webinar: http://salesforce.vidyard.com/watch/PLEr4oLnte-0ZLEO9navtA.
You can also reach out to Customer Support by logging a case via the Help & Training portal.
Theming is a brand new feature coming in the Spring Release ‘15 which has been requested by many organizations for many years now. Themes can be created to change the colors of certain UI elements as well as add a logo to the navigation bar. Multiple themes can be created which is managed through a view in Settings –> Customizations as shown below.
When opening a theme record, you will see a variety of options for UI elements as well as the navigation logo and colors. The logo is a Lookup to a web resource image and can have a custom tooltip for when a user hovers over the logo.
Below is a custom theme in action with a custom Excel logo. As you can see the navigation bar, grid row selection and even the Command Bar buttons can all be customized.
Here is what a record form can look like with a custom theme. Header fields and Business Process Flow links can be customized as well.
Themes can be built brand new or there is an ability to clone an existing theme and make changes. They can also be previewed before publishing to all users. Unfortunately themes are not solution aware at this time but can be exported and imported into a new environment using native record export / import.
Besides branding your CRM system, theming can also come in handy when trying to distinguish your many different environments from DEV to QA to PROD by creating unique themes for each environment.
This post will cover the changes coming to Unified Service Desk around Parature Knowledge Management.
USD and Parature KM
First off are the changes that are coming to USD regarding Parature Knowledge Management.
Users can now perform actions / automations around the Knowledge Base such as Copy Link, Send Email, Link/Unlink KB Article, Browse web pages, etc. within USD sessions.
Also, the KB Search Panel is now independent, and not tied to an entity form. Previously you could only perform a KB search when on a specific record / form. The KB Search Panel can be displayed in different layouts / areas of USD (right panel, pop out, etc.). This provides a much richer experience with multiple applications and session management for the USD Agents.
USD Technical Updates
There were also a bunch of technical updates applied to USD and what actions/controls are available for use.
- A new type of Hosted Control was added for the KM integration (KM Control)
- Inbuilt Actions: Search, SetArticleContext, Associate, Disassociate, SetSearchProps
- Associated Events: ResultOpen, SelectionChange, SearchComplete
- Navigate() action now supports Post-Method for Web applications
- New Actions:
- SetVisualProperty (automate visual properties such as height, width, color, and background)
- CopytoClipboard (allow copy/append text data to the system clipboard)
- New Panel RightPopUpPanel gives an option to display article previews
USD and Parature KM Setup and Install
To install and setup the new functionality for USD and Parature KM, the Package Deployer can be used to deploy all the components needed for the core User Interface Integration (UII) and USD solutions along with sample data to CRM.
Then when in CRM, navigate to Settings –> Service Management –> Setup Knowledge Base Management to setup the record types you want KB management on. You can also configure your Parature connection details from this location as well.
Finally, you need to configure your Parature KM Hosted Control and you should be set to go!
Microsoft recently announced the CRM Online Spring Release ‘15 and subsequently lifted the NDA around the release so we can now blog about all the great new features coming!
This post will cover the feature we’re most excited for in the Spring Release – Navigation enhancements.
New Navigation Bar Shelf
One of the biggest complaints about CRM 2013 / 2015 is that the main navigation was much worse than its predecessors. Users weren’t able to see many entries at once which required them to scroll horizontally for a long time to find the area of the site map they’re trying to navigate to. While this was a pain for all users, it was even more painful for those users who had hundreds of sitemap entries, and trust us, we have customers who fall in that camp. Countless partners and customers started creating their own custom solutions to be able to see more entries at once.
If you’re familiar with the navigation in Dynamics Marketing then you will recognize the new navigation bar that is coming with the Spring Release ‘15. We’re very excited for the new navigation bar as it now provides the ability to see a lot more sub areas on a single screen instead of having to scroll for days if your organization has a lot of entities. Now when you hover over a main tile like Sales, a new shelf will drop down to display a lot more sub sections and links as shown below.
Microsoft is once again listening to the community and adding back features that were in past CRM’s but removed from 2013 (similar to Advanced Find in the global navigation bar). Now Microsoft is adding back the MRU (most recently used) functionality. An MRU icon was added to the navigation bar to the left of the Quick Create icon that will show you a list of your most recent views and recent records as shown below.
Once inside the MRU pane, you can hover over a recent record and click the pin icon to pin that record to the top of the list so it is always visible and easily accessible.
The Quick Create pane was also updated to be a consistent look and feel. It now has the same pane as the new navigation and lists the entities in a vertical manner to be able to show more entities on a single screen without having to scroll horizontally.
A new icon was added to the right of the record name which displays a list of tabs on the form. Clicking a tab name will navigate directly to that tab on the form. This makes it easier to navigate taller forms. It’s also a great way to quickly navigate back to a tab of the main form if you’re currently viewing a related Associated Grid of the main record. Previously in 2013 and 2015, once you navigate to a related Associated Grid, you’d have to go back to the top tab of the form, then scroll down to the tab you’re interested in.
As stated earlier, we are super excited for these enhancements as they have been highly requested for awhile! The one downside is you can only get your hands on it this Spring if you are on CRM Online. On-premise customers will unfortunately have to wait a bit longer until Fall 2015.
For the most part, homegrown things are great. We can get behind homegrown vegetables, flowers, and craft beer. But your homegrown CRM system? That’s another story. For professional services firms in accounting, consulting, legal and AEC, CRM systems are the lifeblood of building relationships and service dollars. And if you want to keep your staff and customers happy, maybe you should start shopping for a CRM that is enterprise-grade, instead of wasting money and manpower on a homegrown CRM system that’s sub-par. Here are 4 reasons why:
1. Homegrown CRM systems don't come with free stuff or shiny new toys
Whether you purchase Salesforce.com or Microsoft Dynamics CRM, by virtue of the platform alone you get access to the tools, functionality, and integrations your team needs. Whether it's reporting, mobile apps, forecasting, user authentication, or especially integrations with tools you use, need and love; incorporating these features into a homegrown CRM system (and maintaining said integrations) would come at an exorbitant cost (and still wouldn’t work as well). Name brand CRM solutions not only give you all this for free, but also constantly deliver new innovations. Both Salesforce.com and Microsoft Dynamics CRM release regular updates 2-3 times a year, and you don't have to do a thing to reap the benefits.
With either platform you never have to build the mobile app or Outlook integration your users clamored for and you constantly get great new things like OneNote integration. A lot of professional services firm use OneNote (and who wouldn't, it's a great tool!) and for Microsoft Dynamics CRM users, no one had to ask for an integration between the two tools: Microsoft built and delivered the ability for OneNote to sync to CRM out of the box. If you wanted to integrate OneNote with your homegrown CRM, it would cost an untold amount of money (and might not even be legal). A huge benefit of buying a CRM, rather than building one, is you get access to the shiny new toys (and tried and true programs) your users will love.
2. Homegrown CRM systems aren't user-friendly
Let me say this another way: a lot of homegrown CRM systems are ugly. And clunky. And your people don't want to use tools that are ugly and clunky. So if supporting user adoption is part of your CRM initiative (which it absolutely should be) good luck getting your team to regularly use a system that is as painful to look at as it is to use. Microsoft Dynamics CRM and Salesforce.com both have teams of UX designers for precisely this reason: CRM solutions must be visually appealing to be appealing.
3. Homegrown CRM systems are difficult to maintain
A majority of the homegrown CRMs we get a glimpse of were built 10-20 years ago, exist on-prem, and look like Microsoft Office applications from the late 90s, or worse, are green screens that only very technical people can touch. All of these factors (and trust us, there are plenty of others) contribute to the fact that homegrown CRM systems can be extremely difficult to maintain. And that's if you hold on to the employee that can maintain them.
Does this sound familiar? "Yeah, we had a guy here in the early 2000's that built our system but he left 5 years ago. No one on staff understands the system, no one can update it, and it's just sitting on our server untouched." Like we said, maintainability is a big issue for homegrown CRM systems.
4. Homegrown CRM systems make customizations painful
Assuming you are one of the fortunate few who have been able to keep their homegrown CRM guru on staff for the past two decades and he/she knows every in and out of the system, this doesn't mean that making changes is easy to do. When it's entirely custom, your CRM expert is likely using duct tape, spit, and prayers to make the system do what you want it to do. On the other hand, Salesforce.com and Microsoft Dynamics CRM allow you to make changes to the system with simple point-and-click, drag-and-drop configurations that require a Business Analyst skillset, not a developer coding away.
If you need someone more technical to make changes, there are plenty of developers you can hire on either platform to work in-house at your firm or as a consultant. Salesforce.com and Microsoft Dynamics CRM also have lots of great partners (like Sonoma Partners *ahem!*) who are very well-versed on the platform, have solved similar problems to yours countless times before, and have helpful tools and tricks to make selecting, switching to, upgrading, and maintaining Salesforce.com or Microsoft Dynamics CRM easier and more cost effective than doing so with internal resources.
Want to learn more about enterprise-grade CRM systems? We're all ears (and solutions).
Today’s post is courtesy of Srilekha Keshava, a Developer at Sonoma Partners.
In the previous post, we have discussed in detail about Sonoma Partners Metablast utility and the benefits of using the tool to generate an entity schema. Today, we are pleased to announce that Metablast has been updated for Microsoft Dynamics CRM 2015. Download the free utility!
Updating Metablast for Dynamics CRM 2015 required only a slight rework, namely matching the latest .NET Framework 4.5.2 to match CRM 2015 compatibility. The UI, connection information, and output remains the same.
As a reminder, once the organization is selected, Metablast displays the list of entities that are available to generate the schema.
A .CSV file with the schema of the selected entities is created.
Entity Display Name
Display name of the entity
Logical/Schema name of an entity
Field display name
Logical name of the field
A short description of the field
Type of field (Example: Option Set, Single Line of Text, etc.)
Is the field Custom or Native
Is the field Optional, Recommended or Required
Is the field Readable
Is the field Creatable
Is the field Editable
On A Form
Is available on the form
Related target Entity for a Lookup field
Relationship used for a lookup field
Option Set values if Type is Option Set
Max Length/Max Value
Maximum length/value of the field
Minimum length/value of the field
Precision Value if Type is decimal
Note: When Metablast is ran against multiple entities, a single CSV file with schemas for the selected entities will be generated.