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.
If you’re like us at Sonoma Partners, and have upgraded to CRM 2015 already, you’re also getting used to the different UI of 2013/2015 compared to 2011.
I may be one of the odd ones where I enjoyed 2011 opening each link in a separate tab (I changed my IE settings to open in a tab, versus a new window). This way I could multi-task and have many different tabs for different records that I was working with.
However, in order to get this functionality with CRM 2013/2015, I now resort to right clicking in a list/grid, and selecting “Open in a New Window” and now I’m back to the navigation that I’m used to.
However, doing this comes with a price of losing some other functionality. Another great CRM feature is the previous/next navigation arrows on a record form to navigate quickly between records from the view you came from.
However, if you right click and open your new record in a separate window/tab as I did above, these arrows don’t appear. If you navigate the way 2015 was built (double clicking a row and having it open in the current window/tab), then these arrows appear.
Just something to be aware of as you choose your own adventure for how to navigate around CRM 2015.
Microsoft’s Convergence was last week and we’re recovering from a long and exciting week in Atlanta but we wanted to share with the community some of the hot topics being talked about in the Dynamics community.
The focus of this year’s Convergence keynote was how Microsoft empowers people, industries and organizations to achieve more. Satya Nadella and Kirill Tatarinov took the stage separately to talk about how Microsoft technologies work together to help transform businesses and while doing so, they announced a handful of new tools.
Power BI is a cloud service that leverages Excel to provide shareable analytics through reports and dashboards. Power BI is now available in the U.S. and more than 140 markets around the world. The following data sources are coming soon – Google Analytics, Microsoft Dynamics Marketing, Zuora, Acumatica and Twilio.
Delve is a new tool which surfaces content from email and social feeds within Office 365. It uses machine learning to highlight information that is relevant based on your work and your colleagues. Delve can surface content from Yammer as well as Exchange Online. It was announced during the keynote that Delve is now globally available.
Skype for Business
Lync has been rebranded as Skype for Business and can now leverage all your Skype contacts. It was announced in the keynote that the technical preview starts today. The full version will be available starting in April.
Microsoft Dynamics CRM was finally discussed towards the end of the keynote when Julia White came out to unveil the new Spring ‘15 Release.
InsideSales Predictive Intelligence
Julia announced and did a demo of Dynamics CRM integration with InsideSales.com’s Predictive Intelligence which helps sales users determine which lead they should be focused on right now by displaying the Neural Score and Contactability front and center on the Lead form.
On the Activity Feed for a record there is a new link for OneNote which lists all the related OneNote entries for the current record.
When a OneNote entry is clicked on, it navigates right to the note in OneNote Online which can then be edited directly in OneNote. This feature is exciting for us as a lot of CRM users use OneNote as well. It provides a better rich-text experience versus the standard text box that CRM provides with native notes.
On the product line items for an Opportunity, there is a “Suggestions” link in each row which will display a list of related products so that they can be easily added to the Opportunity as well with a single click. This feature comes in handy for cross selling or when you’re selling a product that has a lot of related accessories.
With a Windows Phone device, Cortana can now be used to open records through voice commands. Julia said the command “CRM open opportunity called Trek 3D printer upgrade” which then proceeded to open the specific opportunity record in the MoCA app for Windows Phone without any hiccups! I’m still skeptical of how well the voice commands will work but it looks very promising based on her demo and I’m excited to see what else can be done with Cortana and CRM in the future.
Julia briefly showed off the new Outlook 2016 and announced the release of IT Professional and Developer Preview of Office 2016. Attaching a file will now display the most recently used documents. There are also new attachment options so you can use a link to OneDrive or the standard inline attachment. The release version of Office 2016 is expected to be available in the second half of this year.
Lastly, Julia showed off the new Surface Hub on a 84” HD 4k touch sensor screen with WiFi, speakers, microphones and cameras. It supports two-way integration so the content can be manipulated from either the Surface Hub or individual devices that are connected to the Hub and it looked pretty smooth and slick! The Surface Hub website notes that it is coming later this year.
Unfortunately we were hoping for some more stage time for Dynamics CRM but the features that were shown from the Spring ‘15 release look very promising. Now that the NDA is lifted on the Spring release, we will be covering the new features over the next few weeks so check back in the near future!
Whether you're operating in wholesale and distribution, life sciences, or industrial manufacturing; you're well aware that today's global economy and technology explosion have created a hyper-competitive operating environment for manufacturing firms. In order to help your company improve the efficiency of your business processes so you can compete, you've implemented an Enterprise Resource Planning (ERP) tool. Whether it's JD Edwards, SAP or Oracle that you're using, your ERP system allows you to get a real-time view of your entire enterprise. But what about a real-time view of your customer? Have you invested in a CRM system that gives you a comprehensive understanding of who your customer is and what they're purchasing? There are two very important sides of the profitability coin: the business and the buyer; the tools your company uses should address both. When properly integrated, manufacturing firms can experience major benefits from the marriage of CRM and ERP.
1. Consolidated Sales Processes
One specific challenge that manufacturing firms face is supporting two modes of selling: a direct sales team and a distribution channel. Not only are you focused on appealing to your distributors so they push your product, you're managing your direct sales team and their relationships with your clients. So what happens when your direct sales team goes head-to-head with your distributor on the same project? Are you even aware of the overlap before it's too late? A well-implemented CRM system is flexible enough to support the two different modes of selling and get your teams the information they need to ensure you aren't engaging yourself in a bidding war.
2. Increased Visibility and Improved Forecasting
In our experience, we've found that a majority of sellers don't have access to their ERP systems. This is a problem! If you don't have a CRM system and you're storing valuable client and product information that your sales force needs, you have a problem. Because of this lack of access and information, any hope for accurate forecasting goes out the window. When integrated, ERP and CRM systems can give your team real-time visibility into the business data so they can properly sell and have compelling conversations with customers.
3. Cleaner Quote to Cash Process
This is a conversation we have with almost every one of our manufacturing clients. The concept of having to create accurate quotes off of complicated product configurations is an extremely difficult task. But with increased visibility comes an improved quote to cash process (hallelujah!) We know that the product configurations that you create can be very complex because you build to order. Every choice impacts the next and without a deep understanding of the product configuration at the beginning of the project you’re setting yourself up to fail. Unfortunately, we've found that the beginning of the sales process hasn’t paid enough attention to product configurations and how this impacts the entirety of the project’s lifecycle. When CRM and ERP systems are integrated, your sales team can access the information they need at the beginning to accurately quote and deliver.
Now that you’ve addressed the two modes of selling, determined who is responsible for the sale, and integrated your CRM and ERP systems properly, your team is ready to hit the ground running. Or are they? Your field team is on the road having dynamic conversations with customers and they must be able to update content at the point of interaction, not at the end of the day. You have to have a mobility strategy that allows you to update pipeline and quote information on the fly. Mobile CRM applications allow you to capture and document this information, ultimately helping you to engage and make better decisions for your customers based off of order information, historical purchases, and current production schedules; all accessible with just a swipe and a tap.
5. The Distributor Portal
A trend that we are currently seeing in manufacturing is an increased focus on keeping existing customers, rather than winning new business. This means that once you’ve made the sale, you have to pivot your attention to keeping the conversation going. Manufacturers, repeat after me: cross-selling is your friend. And how can your team cross-sell more effectively? Through portals updated with information from both ERP and CRM systems. Portals allow you to see where in the manufacturing process an order is, check the status and delivery of past orders, and see the account in real-time. All of this information gives you valuable insight that can help you make the next sale while keeping your existing customers in the know.
CRM is no replacement for ERP and ERP is no replacement for CRM, but the integration between these two systems is essential to increasing collaboration between departments. If you're considering integrating a CRM tool with your existing ERP system, remember this: the key is to create two systems that are tightly integrated and designed in a way that creates a customer-centric environment.
Want to learn more about CRM and ERP integrations for manufacturing? We can get you get actionable data into the right people's hands at the right time to keep your sales and production cycles moving forward.
In part 1 of this series, we looked at the new feature released in Spring ’15 called Lightning Processes and we did a basic comparison between it and Worflows. In part 2, we looked at how to use Lightning Processes to create and update related records. In today’s post, we’ll be looking at how to extend the Lightning Process Builder beyond it’s out of the box capabilities by invoking Apex inside your Processes.
While the Process Builder is very flexible out of the box, it cannot do everything. Salesforce realized that there would be scenarios they couldn’t cover by default, so they allow us to extend the Process Builder by writing Apex code that meets certain criteria, and then invoking the Apex from our Processes.
As an example for today, let’s say we have a custom field on Account called Sample Field 1, and the requirement is whenever Industry is changed we want to copy the value to Sample Field 1.
While we could use a standard field update or a formula field to achieve this, we’re going to use Apex so that we can see how we can extend Processes to do something much more complicated.
To start, we need to learn about a new Apex annotation introduced with Spring ’15: @InvocableMethod. This annotation lets us mark an Apex method as being something that can be ‘invoked’, or called, from somewhere other than Apex. In our case, we’re going to call it from a Process. It also defines some metadata about the method like a human friendly label and description of what the method will do when it’s called. There are some specific requirements that must be followed to make a method invocable, so make sure you read the documentation carefully. In our case, the code is very simple:
Once we have this class saved, we can go to the Process Builder and use it. Most of the setup is the same as before, but when choosing an action to perform we’ll now chose a type of Apex:
Once you’ve filled out the required fields, you’ll have a process that’s now calling your apex class!
To test it out, let’s first try updating an existing record:
That worked! Now let’s try it when we create a new record:
That also works. In general, processes get executed after the record has been soft saved to the database (roughly the same time that workflows would run), so they have an ID already by the time this Apex executes.
When I first wrote this Apex class, I wasn’t originally looking up the record from the database and updating that copy. I tried to instead update the record directly:
It seemed like I should be able to do this, since this is what I would do in a before trigger normally (I also hadn’t yet figured out when exactly Processes run in the pipeline – in hindsight it’s obvious this wasn’t going to work). When I attempted to run the Apex which updated the record directly, I got a nasty error on the form:
Unfortunately, that’s all the detail you can get from the user’s point of view, which isn’t super helpful. There also doesn’t appear to be a way to customize how it’s displayed, which is slightly disappointing. If you’re an administrator in the organization, you’ll receive an email which is more helpful:
The important thing to note here are the Process ID in the email and the details of the Apex error. The Process ID corresponds with the ID the user sees in the error message and can be used for correlation if multiple Processes are having problems. In my case, I was more interested in the Apex details, which states that the records that are passed in to the Apex class are read-only.
Obviously this example is very simple, but the Apex you use could be quite a bit more complicated. The core lesson here is that we can invoke Apex from Processes if we give it the appropriate annotation and follow the rules in the documentation, allowing us a greater degree of freedom. We hope you find this new power useful. If you come up with any creative ways to use Processes, please feel free to share in the comments below!
The Salesforce Admin's Toolbox is written by Megan Burch, a Salesforce Business Analyst at Sonoma Partners.
Disclaimer: This is considered a URL hack, which is not supported by Salesforce. Salesforce can change undocumented query strings at any time. Also, field ID’s will likely change between environments. Sonoma Partners has code that can resolve this issue. Please contact us for more information.
With Salesforce, pulling information from one object to another with formula fields and workflow field updates is easy. However, sometimes users need to see information or for usability purposes have information pre-populated before they save the record. Custom buttons are a great solution for this. In this edition of the Salesforce Admin’s Toolbox, I’ll outline how to create a custom New Opportunity button on the account related list to pre-populate account information onto a new opportunity form, as shown here:
1. Create a New Button
To create a custom button navigate to the “Button, Links, and Actions” option from the object you want to create the button. For this example, we will create a new button on the Opportunity. The first thing you’ll want to set is the display type, which determines the layout of the Salesforce side bar and header on the new page.
A “Detail Page Link” button will show up next to the custom links on the detail page.
For this example, I created a “List Button” on the Opportunity object. The custom button will show on the Opportunity related list on the Account page (or any other object with an Opportunity related list). Next, we’ll choose a behavior. This gives you an option of how you want the new record to execute. Display in existing window with sidebar will run the flow in the same window you are in, showing the Salesforce sidebar.
Display in existing window without sidebar will run the flow in the current window, without showing the Salesforce sidebar.
Display in existing window without sidebar or header will run the flow in the current window, without showing the Salesforce sidebar or standard header.
2. Understanding the URL
Copy and paste the URL into your custom button and remove everything before the first forward slash, and everything after retURL, so it looks like this:
Writing the rest of the URL will be easier once you understand the above string.
006 - Each object has an ID in Salesforce. The 006 indicates that the URL will take you to an opportunity record.
You can find a complete list of Object IDs here.
/e - This is the action being taken on the record. In this example, e is for edit.
? - This denotes the beginning of a querystring. Everything after the question mark are name/value pairs that the browser natively interprets. As you will see, we’ll supply a few parameters that Salesforce will interpret for us, such as variables (fields) are included, Salesforce will search the parent object and match up fields on the child object in order to populate them with default values.
retURL - This indicates our originating record and where the information should be pulled. In this case, it will be the account record that I clicked.
3. Populating Fields
Before I can populate the additional fields, I need to tell the button where to pull the fields from (the Account). From the “Insert Field” drop down I selected Account ID and the system inserted it as a merge field.
The beginning of the URL should now look like this:
Now that I have the base URL for the button, it’s time to populate the fields. In addition to the pre-populated Account Name, I’m also going to populate the Industry and Account Phone number with information from the parent Account.
To populate the fields on the Opportunity, I’m using this general format:
Opportunity field ID = Account field name
I’m getting the Opportunity field IDs by navigating to the field in the Opportunity set-up and opening it. The ID will be in the URL string once the field is clicked.
Note: ID’s for custom fields will differ between sandbox and production environments.
I’m getting the Account fields using the “Insert Merge Field” drop down I used to get the Account ID earlier. Once I have those two pieces the URL will look like this:
Next, I am going to populate the Industry field on the Opportunity. I created a custom Industry field on the account as a lookup field. Lookup fields need to be entered slightly differently in custom buttons. The Opportunity field ID = Account field name needs to be entered twice, once with the appendage “_lkid”, and the prefix “CF”, if it is a custom lookup. Our example will look like this:
Now the complete button looks like:
4. Adding a Custom Button to a Related List
Our last step will be to add your custom button. Navigate to the edit page layout screen. Scroll down to the Opportunity related list and click the wrench. Click the buttons box, un-check the standard new button and select the new button.
Now, when you click on the button the Opportunity record will open with the Account Information fields pre-populated:
Understanding how custom buttons work and how to create them is one of most beneficial Salesfoce tricks I’ve learned. Custom buttons have countless applications and will help you unock creative solutions to maximize your users’ Salesforce efficiency.
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.