Sonoma Partners Microsoft CRM and Salesforce Blog

Avoid Form Script Errors with CRM Online 2015 Update 1

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.

SNAGHTMLc046f23

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.

    image
  • 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!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM Online

Invocable Actions Part 4 – creating a custom action

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:

/services/data/vXX.0/actions/custom/apex

0

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:

1

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.

2

Promoting Reuse

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.

Wrap Up

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.

Topics: Salesforce

Invocable Actions Part 3 – using an action

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

/services/data/vXX.0/actions/standard/chatterPost

0
In the returned metadata, we can see that this action wants 3 parameters: Message, Target Name or ID, and Target Type.

For our example, what we want to do is post a new message to chatter saying “It worked!” in the default public group:

1

2

We can accomplish this by filling in the various inputs and sending a POST request to the same url:

3

4

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.

5

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

Wrap Up

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.

Topics: Salesforce

Introducing Dynamics CRM QuickNav Solution

 

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.

quicknav

The recently launched Microsoft Dynamics CRM Spring 2015 Release provides a much needed usability facelift to the main navigation as shown below.

carina_nav

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

quicknav_find

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!

Topics: Microsoft Dynamics CRM 2015

CRM Online Spring 2015 – Plug-In Trace Log

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.

image

  • Next, utilize the ITracingService to write out a trace and/or throw an Exception within a plug-in

image

  • 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

image

  • Now Navigate to the new link in Settings –> Plug-In Trace Log

image

  • You should see a grid of all the Plug-In Trace Logs per plug-in execution

image

  • 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.

image

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.

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM Online

Invocable Actions Part 2 – Discovering your web services

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.

0

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.

1

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).

2

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

/services/data/vXX.0/actions/standard

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.

3

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

/services/data/vXX.0/actions/standard/XXXX

4

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

/services/data/vXX.0/actions/custom

endpoint instead of the standard endpoint. In the case of custom actions, the results are grouped by the type of action as well:

5

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.

Wrap Up

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.

Topics: Salesforce

CRM Online Spring 2015 – Folder Level Tracking

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

image

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. 

image image

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!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM Online

Introducing: Tree Log

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.

0

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.

1

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.

Topics: Salesforce

How Changing Nothing Can Change Everything: M.Holland & Mobility

"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
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.

Task List
Task List
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.

The result

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.

 

Get a working custom mobile app for your CRM system

 

Topics: CRM for Manufacturing Enterprise Mobility

Invocable Actions Part 1 – Salesforce web services revisited

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.

Topics: Salesforce