Sonoma Partners Microsoft CRM and Salesforce.com Blog

Salesforce Made Smarter with Einstein

Today's blog post was written by Troy Oliveira, Principal Developer at Sonoma Partners.

Unless you have been living under a rock, you know that the big announcement out of Dreamforce this year was Salesforce Einstein, Salesforce’s Artificial Intelligence (AI) engine. But you probably have also spent some time wondering what the announcement means for your business and your day-to-day interaction with the platform. 

A common sentiment we hear is, “Einstein sounds great, but what does it really mean for me?” The answer to that it is as complex as AI itself. In short, I try to tell folks that this is an investment in the platform, and as with any investment, it is likely going to take some time for everyone to see the benefits. Some will see immediate benefits, while others will be waiting for awhile as Einstein becomes more widespread.

One thing is for certain: AI is the future, and Salesforce is committed to bringing AI into your business processes.

Making Salesforce the World’s Smartest CRM

The world is creating and storing new information at an astounding rate, and the amount of data that we are creating keeps rising on a day-by-day, hour-by-hour basis. For most of us, the question isn’t about not having enough information to make decisions, it is the exact opposite. We are flooded with too much information and cannot tell what is important and what is just white noise. That is where Einstein comes in.

Salesforce loves to use the following equation to describe how Einstein works and what it means to you.

Customer Data + AI + Salesforce Platform = World’s Smartest CRM.

Troy einstein 1

Through a combination of predictive analytics, machine learning, and natural language processing, Salesforce is able to comb through the data already in your Salesforce ecosphere and give you a better glimpse into what that data means as well as make suggestions and predictions on how you can act upon it.

As a salesperson, imagine the possibilities if you could focus your efforts on pursuing the best leads - not by guessing, but by using AI lead scoring to tell you based on what has actually happened in the past who the best leads are for your business.  Or a Marketer who can now segment their audiences by predictive open rating and send emails to every recipient at the exact right time.  Or a Customer Service Representative who is automatically prompted by case resolution steps and recommended responses?  This is the power of AI in CRM and that is what Einstein brings to Salesforce.

What does that mean for me, right here, right now?

This all sounds great, but what does it really mean for you today?

First, if your company or organization is using Salesforce Classic, you’ll want to consider moving towards Salesforce Lightning Experience. As with a lot of the new, shiny features that Salesforce has been releasing and will continue to release, the biggest benefit from Einstein is going to be found by those who are using Lightning Experience.

Second, since Einstein is machine learning and predictive analysis of YOUR data, the more data you have in Salesforce, the more accurate the predictions will be, and they will improve as you get more data into the system. That’s why it is called machine learning. The benefit to this is that your organization has predictions that are specific to you, not some generic model developed in a basement somewhere. The downside is that if you have bad data, you’re going to get bad predictions.

Lastly, keep an eye out for the future. At Dreamforce, only 17 Einstein features were announced, but we expect that number to grow tremendously over time. Meaning, if there isn’t something that you are interested in today, that doesn’t mean that Einstein isn’t right for you. Start taking the steps above to improve your data and work toward moving in the Lightning Experience direction because you never know what is coming in new releases.

How can I be a better consumer?

Keep an eye out for more information. I’ve linked to a number of blog posts that go deeper into how Einstein works and what it means for the different Salesforce clouds. Obviously this post isn’t meant to be the definitive source of information on Einstein, but we hope it can serve as a stepping-off point.

If you have any questions about Salesforce Einstein, Lightning Experience, or need help implementing your solution with Salesforce, please contact us.

Topics: Salesforce.com

Fiddler is Your Data Migration Companion

Today's blog post was written by Keith Mescha, Principal Architect at Sonoma Partners.

Here at Sonoma, we are a big fan of KingswaySoft’s tools for data migration to Dynamics 365 and Salesforce. We use SQL Server Data Tools and SSIS all the time for data migrations and integrations to CRM for our clients. The tool set they provide is an add-on that allows us to quickly read and write data from the cloud. In one recent migration project, we ran into an odd issue that took a bit to figure out. Here's what happened...

Within the KingswaySoft CRM Online adapter, there is built-in functionality to do lookups for related fields based on text provided. This will allow you to provide the text value, and it will retrieve the GUID for you to populate in the target entity. In this case we were using this functionality for loading Opportunity Products and using text lookup for the Unit of Measure attribute. This attribute is required on this entity, but we are not really using Units of Measure so we just needed to retrieve the default ‘Primary Unit’ GUID.

Destination Editor

So we wired this all up and started to push our data however nothing was happing. The process just appeared to hang, and we did not see any data show in CRM. No obvious errors were being returned by the KingswaySoft CRM adapter to tell us anything was wrong like we typically see. We started looking at plugins and workflows on the target org. We played around with various batch sizes, but still nothing was happening.

After some head scratching we decided to fire up Fiddler to see what we could find in the messages being sent between our process and CRM Online. We quickly noticed that we were getting 500 errors for every call to CRM. In digging into the messages, we were getting an error that ‘UoM entity does not contain attribute with Name = ‘statecode.’ This didn’t make any sense at first, but then we remembered there is an option in the Text Lookup function to Exclude Inactive and realized very quickly this must be our issue. So we unchecked this box, and our process started working and records migrated into CRM.

Error Code

This seems like a defect in the product, and we will report a bug to KingswaySoft but figured if anyone else ran into similar issues this might be of some assistance.

The key takeaway here is that for data migrations with CRM Online, Fiddler is your friend for pulling the curtain back to see what’s really going on with some of the calls that the data migration tool set might be gobbling up and not exposing. Oh and don’t check this box if using Text Lookup on the UOM entity as there is not a statuscode field on that entity in CRM apparently.

Text Lookup Editor

Topics: Microsoft Dynamics CRM

Extending the Dynamics 365 Editable Grid

Recently we blogged about the functionality of the new editable grid in the Dynamics 365 release.  One thing we pointed out in the post is that the editable grid doesn’t respect read-only fields on the form.  For example, if I have the Email field on the Contact form set to read-only and I use an editable grid for a Contact view that contains the Email field, it will allow the Email field to be editable.

One way to make the field read-only in the editable grid as well, is to write custom JavaScript.  In order to do so, we need to utilize the OnRecordSelect event of the editable grid.  First, create a JavaScript web resource with a function called onrowselect.  For the scenario of disabling the Email field on the Contacts sub-grid, the code will look like this:

function onrowselect(executionContext){
    var entityObject = executionContext.getFormContext().data.entity;
    entityObject.attributes.forEach(function (attribute, i) {
        if (attribute.getName() == "emailaddress1") {
            var emailControl = attribute.controls.get(0);
            emailControl.setDisabled(true);
            break;
        }
    }); 
}

The code uses the execution context to get a reference to the entity and then loops through each attribute to find the email attribute and then disables the control.

Now that we have the JavaScript web resource with the necessary function, we need to hook the function up to the editable grid.  Navigate to the form customizations where the editable grid is located.  Open the properties for the grid and there will be a new tab labeled “Events”.  Select “Events” and in the “Event” dropdown, choose “OnRecordSelect”.  Add your new JavaScript web resource and set the Function to “onrowselect” and be sure to check the option to pass in the execution context.

image

Click OK, save the form and publish customizations.  Now, navigate to your editable grid and when you select a row to edit it, the Email field should be disabled.

image

This is quick and easy to implement but the caveat here is that you need to apply this JavaScript to every editable grid for the desired entity, if it has a field that should be read-only.

Topics: Microsoft Dynamics 365 Microsoft Dynamics CRM

You Gotta Know the Territory: Part 3

Today's blog post was written by Troy Oliveira, Principal Developer at Sonoma Partners.

So far, we've taken a look at Account Teams and Enterprise Territory Management in the previous posts in this series. The final post in this series is a short one, but don’t let the length of this post fool you; custom solutions are incredibly powerful options for solving complex territory management problems.

Custom Solutions

If neither Account Teams nor Enterprise Territory Management provides the solution that your company needs in order to handle your sales model, a custom solution might be your best option. We have successfully implemented several different options when it comes to creating an efficient custom solution for solving some very complex scenarios.

The biggest benefit of a custom solution is that most of the restrictions around the structure and automation of a model can be accounted for, typically through a combination of custom Apex code, Workflows, and Processes. Even better is that because all of the underlying information for Account Teams and Enterprise Territory Management can be queried in code, a fully automated hybrid solution could be created using one of the already existing territory modeling tools already mentioned. A great example of this can be found in this post by a colleague. It is also prudent to keep in mind that Enterprise Territory Management rules cannot be re-evaluated from code; any changes requiring the rules to be re-evaluated would require manually clicking “Run Assignment Rules” in the Salesforce UI.

While the custom solution option is a great way to tick off boxes in your organization’s requirements, keep in mind that you are still dealing with custom code. Since we fully recognize that territory models are fluid and change periodically, when we build a custom solution for our customers, Sonoma Partners takes great lengths to ensure that as much of the solution is configurable as possible. This helps reduce the need for someone to have to update and deploy code whenever changes occur to the territory model.

In Summary

If you’ve been following this series, you know what’s next. Pros and cons!

Pros: Cons:
  • Can handle more complex rules
  • Not native, needs to be tested with every upgrade
  • Automated processing
  • Requires understanding of coding
  • Can be combined with native functionality
  • Some functionality may be limited

Now that you’ve gotten a better idea of what territory management options are available to your organization, you can ensure that your salespeople know the territory.

If you have any questions about territory management or need help implementing your solution with Salesforce, please contact us.

Topics: Salesforce.com

Dynamics 365 Editable Grids

As with any release, the recent release of Dynamics 365 has introduced a bunch of new features.  Head over to the CRM Roadmap site, or the CRM What’s New site to see first hand the features that have recently gone live.  In this blog we’ll talk about one of those new features we’re really excited to see get added to the project:  Editable Grids.

Editable Grids

One of the most sought after features since I’ve been working on Dynamics CRM is editable grids.  The mantra of Dynamics CRM for the past 15 years has been read only lists/views, and a single record form to modify the data.  In most of our implementations, we’re asked to create an editable grid to allow users to more quickly modify data.  We even took our client specific editable grid solution, made it generic, and provided a free version of it for Dynamics CRM 2011/2013/2015/2016 for the community to download from our tools site.

However, Microsoft has released the ability to turn any grid in Dynamics CRM into an editable grid with their latest release of Dynamics 365 for Sales.  Upon this announcement, I believe I heard all of the developers at Sonoma Partners let out a loud cheer as working with editable grids is a pretty challenging task.

Note that this new editable grids functionality is available for sub grids (that appear on forms) as well as home grids (the grid that shows when you select an entity from the Site Map, or when you expand a sub grid on a form to be full sized).  And as you can see below, editable grids are supported on the web, phone and tablet clients.

What’s supported on the editable grids?  Is everything you’re used to with a read only grid and record form supported?  The quick answer is that yes, everything you can do with a read only grid you can do with an editable grid (plus more):

  • In line editing
  • Sorting
  • Grouping (see below)
  • Filtering
  • Pagination
  • Calculated and Rollup Fields
  • Run time resize/move columns (see below)
  • Auto Save / Manual Save (see below)
  • Toggle between read only and editable grid (see below)
  • Filtered lookups
  • Chart panel interaction
  • Command bar interaction
  • Business Rules (e.g., show error messages, set field value, set business required, set default value, lock or unlock)
  • JavaScript

Enabling Editable Grids – Home Grid

To enable the editable grid for a home grid, first go to customizations for the entity at Settings –> Customizations –> Customize the System –> Entities, and then click on the Controls tab for an entity you want to configure.  In my example below, I’m working on the Account entity.

image

By default, the Web/Phone/Tablet will all be using the legacy read only grid.  However if you click on the Add Control link, you can select the Editable Grid control in the dialog that pops up, and click on Add.

image

You’ll then have the option to enable the editable grid for the Web, Phone, and/or Tablet experiences by selecting the appropriate radio buttons.  For now, we’ll just enable it for the Web.

image

 

Enabling Editable Grids – Sub Grid

For a Sub Grid, navigate to the form that the sub grid is on and find the sub grid you want to make editable.  Select the sub grid on the form, and click on the Change Properties button in the ribbon.  In the dialog that appears, select the controls tab, and click on the Add Control link.  As with the main grid, you can add the Editable Grid control, and then configure in the sub grid properties dialog which form factor the editable grid applies to (web, phone, and/or tablet).  We’ll choose just Web once again for the Contact sub grid on the Account form.

image

Configuring the Editable Grid

Whether you enabled a Main Grid or Sub Grid to use the Editable Grid control, the configuration is the same.  Once you add the Editable Grid control, you’ll see an Events tab appear.  This allows you to configure JavaScript code that will trigger on certain events that occur in the grid.

image

This is very similar to the Form Properties dialog where form JavaScript libraries are configured at the form level.  The events currently exposed by the API for editable grid JavaScript libraries are:

  • OnChange (when a particular field is changed)
  • OnRecordSelect (when the user selects a record)
  • OnSave (when a record is saved)

In addition to adding JavaScript to your editable grid, when you have the Editable Grid row selected in the Controls tab, you’ll see some configurable options at the bottom of the dialog.

image

The Add Lookup link allows you to configure how a lookup will work in the grid.  You don’t have to add a configuration option for a lookup.  However, with this option, this allows you to configure filtered lookups for a specific view, just like you’re able to do on the form.  Therefore if you have filtered lookups on the form, it’s strongly recommend you configure your lookups on the editable grids via the Add Lookup link.

image

The Nested Grid View and Nested Grid Parent ID are used to display a grid within a grid.  Note that this functionality is only available on and Tablet.  Clicking on the pencil icon next to these settings will allow you to select the entity to be shown in the nested grid, along with the parent lookup field on which the related records should be fetched.

The Group by Column setting allows users to select the Group By option on the top of the grid when actually working within an editable grid.  Group By is different than sorting on a column in that it will put records into an expandable control based on the field that you have grouped by.  Only the fields in the current view will be options in the Group By dropdown.  Groups can be expanded or collapsed.

image

Using the Editable Grid

After you have your grid configured, your users can simply click into a field to be able to edit the value in the field without opening the record form.  You can also quickly change fields via the keyboard (tab) or mouse.

To save the updates you made to the record, you can simply click off to another record, or click on the Save icon in the top right corner of the grid.

image

Users can also change the grid between the new editable version shown above, and the classic read only version via the Show As button in the toolbar.

image

Also note that the columns in the grid can be reordered per user per view.  The column order, group by setting and sort order is persisted throughout the application until the user clears their browser cache.

Considerations

With the new editable grid functionality, there are a handful of tips and considerations to think about as you’re configuring your CRM deployment.

  • The Editable Grid doesn’t respect read-only fields on the form since that isn’t a legitimate way to control security.  To prevent users from editing these fields, you’ll need to either add field level security to the field, not put that field in the view, or write JavaScript (this will be covered in a future developer related blog post).
  • The Editable Grid version of a sub grid takes up more space than the read only grid (especially if you enable the Group By feature).  Allow for a larger sub grid to make sure your users see the same amount of data they used to.
  • Enabling editable grids on a home grid is a global setting meaning that wherever you see that entities home grid it’ll show as an editable grid (e.g., tiles clicked from anywhere on the Site Map, sub grids that are expanded to the full grid).
  • Enabling editing on a sub grid is a per sub grid basis meaning that every sub grid on every form and dashboard must have their editable setting enabled individually.  You could have the situation where the sub grid doesn’t have the editable grid enabled, but the home grid for that sub grid does have the editable grid enabled.  In this scenario, if the user clicks to expand the sub grid to the full grid, they’ll go from a read only grid to an editable grid.
  • Some fields are not editable in the editable grid:
    • Fields from related entities
    • StateCode
    • Customer fields (e.g., on an Opportunity or Case)
    • Composite fields
    • Party List fields (e.g., the To field on an Email)
    • Field Level Secure fields (if your field security profile prevents you from editing the field)
Topics: Microsoft Dynamics 365 Microsoft Dynamics CRM Microsoft Dynamics CRM Online

Redefining a 360-Degree View of Your Customer

Today's blog post was written by Kyle Dreyer, Principal Architect at Sonoma Partners.

The genesis of nearly all CRM implementations comes from the desire to see a 360° view of your customers.

This typically involves the desire to see Contacts, Opportunities, Cases, Orders, etc. for an individual customer in an intuitive user interface. This provides a sales organization and customer service organization (as well as other business groups) insight into all activities around a customer. It is not difficult to realize the value that this brings.

The question now becomes – how do we take that to the next level? We are consistently hearing from our clients that they expect to have visibility from their account hierarchy to the data that resides within child accounts.

Imagine the following scenario of a customer hierarchy:

Kyle d 1

It is easy to see the logic that users would want to see Opportunity/Cases/etc. that reside in Division 1 and 2. Additionally, at the Holding Company level, users want to see everything that is occurring at Company A, B, and C – as well as what is occurring at each division.

So, how do we do this? This would, in theory, be possible with native reporting, but reporting across an inconsistent hierarchy (it won’t always be as simple as the example shown above!) can be challenging in reports. Additionally, you would either need to create a report for each account or provide the ability to change the parameter that the report is using (which, in the Salesforce world, would also give users additional reporting access that is not always ideal!). Lastly, users will want to see this data on the account record that they are currently working on.

Build Steps

The good news is that all of this can accomplished relatively easily using configuration. Let’s take a look at how to do this in Salesforce (for this illustration, I’ll show this capability on an Opportunity):

1. Create Account Record Types

Kyle d 2

*In this example, I’ve created generic record type names. More descriptive ones may be appropriate.

2. Create fields on the Opportunity object called “Parent Account” and “Ultimate Parent Account”

Kyle d 3

3. Create an Account Page Layout for Each Record Type

Kyle d 4

4. Map Account Page Layouts to appropriate Account Record Types

Kyle d 5

5. Add the appropriate Opportunity Related List to each Account Page Layout

Kyle d 6

*The above related list should be placed on the “Account Layout”

Kyle d 7

*The above related list should be placed on the “Parent Layout”

Kyle d 8

*The above related list should be placed on the “Ultimate Parent Layout”

6. Make Parent Account and Ultimate Parent Account Read only on Opportunity Page Layout(s)

Kyle d 9

7. Use Process Builder to auto-populate the Parent Account and Ultimate Parent Account when an Opportunity is created

Kyle d 10

Kyle d 11

Kyle d 12

Kyle d 13

Formulas:

  • Parent Account:
    • IF([Opportunity].Account.RecordType.Name = 'Grandparent', [Opportunity].Account.Id, IF([Opportunity].Account.RecordType.Name = 'Parent', [Opportunity].Account.Id, [Opportunity].Account.ParentId))
  • Ultimate Parent Account:
    • IF([Opportunity].Account.RecordType.Name = 'Grandparent', [Opportunity].Account.Id, IF([Opportunity].Account.RecordType.Name = 'Parent', [Opportunity].Account.ParentId, [Opportunity].Account.Parent.ParentId))
  • Activate the Process Builder and test it out!

Testing

In order to test this process, I’ve built out the account hierarchy in our previous example.

Kyle d 14

I created an opportunity on the Account “Division 1”, “Customer C”, “Customer B” and the “Holding Company” – lets check out the results by viewing the pages of these accounts.

Holding Company:

Kyle d 15

Customer B:

Kyle d 16

Customer C:

Kyle d 17

Division 1:

Kyle d 18

Additionally, the opportunity on Division 1 should “roll-up” to Company A (I’ve already shown this rolling up to the Holding Company) since its parent account is Company A. Let’s take a look at that account:

Kyle d 19

Requirements/Other Considerations

Now that we’ve shown how this functionality would work, I should mention a few considerations/requirements:

  • Define the maximum depth of the hierarchy.
    1. In this example, I’ve shown a 3-level hierarchy. There is no requirement to the depth that the hierarchy needs to be. That said, a maximum depth must be set. The greater the depth, the more complicated this becomes. I would encourage you to limit the hierarchy to 4 levels deep.
  • This is a simplified example.
    1. You’ll notice that the formula in the process builder is pretty straightforward. This design would allow for more complicated scenarios to determine the Parent and Ultimate Parent accounts on the Opportunities.
  • This is extendable to more child objects to an account – or any objects with a hierarchy.
  • Do not extend this to all objects related to an account.
    1. This design is not suitable for all objects. For example, we rarely (if ever) do this for Contacts. Often times, the number of contacts in the system would be overwhelming (and thus reduce the value) at the highest level in the hierarchy.

Summary

I hope that helps your organization consider the value of re-defining a 360° view of a customer. Our clients have found this to be instrumental to the way that they operate their business. You can imagine the benefit of “rolling up” certain objects (who doesn’t want to know the total dollars from orders that they do with a customer?). As always, should you have any questions, please do not hesitate to contact us!

Topics: Salesforce.com

Metablast Updates

With the changes in Dynamics 365 and the introduction of AppSource as a way to showcase apps, it was time for Metablast to make a few changes. We are happy to announce that we have launched a Managed Solution version of Metablast, now available in the AppSource and download from our website for On-Premise Microsoft Dynamics CRM users! 

The Managed Solution version of Metablast supports Dynamics CRM 2016 and up, so if you are on a previous version of CRM the previous version of Metablast will work for you. All the features of our prior versions detailed in prior posts are included, with the addition of two new output columns:

  • Global Option Set – Displays Yes or No for Option Set fields to show the field is a global option set reference (Yes) or a local option set (No)
  • Formula – Displays Yes or No based on whether or not the field is a formula field (editor’s note: an update will be posted soon, at the original time of posting the output is the XML formula itself and not a Yes or No)

Once the solution has been added to your org, you can open the solution and view available entities in the configuration page. The left list contains available entities not yet selected for the export, and the right list contains entities you have previously selected.

Metablast 1

Typing in the search box filters the list of entities to make finding and making selections easier. Note that the check mark in the list denotes whether or not an entity is custom versus native.

Metablast 2

Selecting each entity will add it to the export list. The Add All link will add all unselected entities to the export list. Removing entities from the export list can be accomplished by clicking the red X or the Remove All link to do so en masse.

Metablast 3

Once your list is complete, you can click the Export button and download the same CSV format as your prior Metablasts.

Metablast 4

We hope you find the same great uses out of this tool with an easier way to access the schema information right from your organization!

Topics: Microsoft Dynamics CRM

How Professional Services Firms Can Crawl, Walk, Run with CRM - Part Three

Today's post was written by Bryson Engelen, a Sales Engineer at Sonoma Partners.

Professional services firms know how critical it is to their business to implement or improve a CRM system, yet oftentimes the way they approach an implementation can doom them to failure. One of the major problems they encounter is in trying to please everybody all at once. Their "boil the ocean" approach overwhelms users and delivers too much, too soon. Instead, it’s better to think of a CRM as a living, breathing thing, and build upon it over time based on how people actually work, not how they think they work. This can only be done by adding to a CRM system with a well-thought-out crawl, walk, run approach, keeping users at the center of an ongoing conversation.

In this blog series, we take a look the common use cases for professional services firms as they try to master the basics (crawl), start using CRM on a more strategic level (walk), and then leverage CRM as a platform to solve business problems that would otherwise require custom solutions (run). Think of these suggestions in each phase as an a la carte menu, and in some instances the phase designations may not perfectly suit your firm, so you may implement what is described as a “walk” item in your “crawl” and vice versa. In our last posts, we looked at some of the “crawl” and “walk” items for professional services firms. This time around, we’ll round out our exploration of this topic by discussing “run” items.

When discussing a “run” item on your CRM list, think of existing systems you bought or built that really only handle a discrete process or think of workloads that touch core CRM that you just have a process and no system around. Having implemented CRM in the “crawl” and “walk” phase, hopefully you have gotten feedback from users on other things they would like CRM to handle or you have uncovered related processes in your earlier CRM requirements gathering.  In some instances, you can build Line of Business applications from scratch in CRM to handle these, and in others you can explore enriching existing systems with integrations into your CRM, potentially using CRM as a front-end to the process. Here are some examples of how your firm can retire application cost and maintenance energy by folding processes into CRM.

1. Internal Business Apps:

There are a lot of apps that can be built or bought that help automate your internal processes, and they can plug and play into your existing CRM infrastructure. For many professional services firms, things like logging time and expenses, activities, and event attendance happen in tools outside of CRM or in a spreadsheet. These activities are critical to running your business and understanding internal costs, but users don’t like that they need separate tools to enter this information. CRM provides a great opportunity to build or buy apps to handle these workloads and places that information right alongside client data. For example, a simple activity logging app on a phone can make the process of recording phone calls and notes against a client in CRM fast and easy, and greatly increase the amount of client relationship documentation. Tools like a Client Mapping tool can be a mobile app built on top of CRM that allows users to find info on nearby clients, while event attendance tracking apps (like one built by Sonoma Partners) allows mobile users to quickly and easily add people to marketing lists on the go. If you have internal processes that are critical to your business but that data is being lost because it’s hard to get into a system and maintain, maybe you can offload that to CRM via a discrete app.

2. Client Portals:

Oftentimes, information and documents need to be exchanged with clients regarding projects, pursuits, contracting, etc. CRM can not only provide flexibility around managing documents related to clients (and store those documents within CRM against the client record), but it can also expose select documents and CRM data to clients as needed. CRM also brings self-service to the table in other ways, allowing clients to request help or service, review a project’s status and other details, select and download thought leadership and marketing collateral and see upcoming meetings and milestones which provide a centralized calendar for you and your clients. You can even configure a client portal to offload some data entry from your staff to your clients by allowing them to submit data like feedback or referrals and event RSVPs. Overall, since CRM is already how you manage clients internally, it makes sense to use the same tool for externally-facing client management processes.

3. Project/Resource Management:

Many professional services firms have project and resource management tools, but they don’t tie into client data directly, leaving a disconnect between business development and project management activities. CRM has built-in or plug-in capabilities related to managing projects, resources, expenses, time entry and more, depending on your use case. If your use case is complicated, there are plenty of 3rd party apps that might be easier to implement and have a lower cost of ownership. That being said, using CRM for things like housing a skills database, generating resumes (particularly with a CRM-driven resume update portal), creating an employee scheduling portal/app and doing resource allocation is possible with some existing functionalities and add-ons. Additionally, you can leverage native CRM tools and beyond that build or buy apps for CRM around project planning and project management via a portal or mobile app.

4. Internal and External Social/Collaboration Tools:

Social tools tied to CRM can be a better way to collaborate internally and externally, particularly around shared content like proposals. Often, the tool itself is pretty intuitive, particularly in this age of Facebook, but to make it work, your culture has to embrace a spirit of collaboration and not be tied to individuals “owning” things. If that cultural hurdle can be overcome, the results and efficiencies gained from social tools can be pretty dramatic. Say someone in one of your departments puts together a one-sheet that he wants to send to his clients, and recognizes it could also be beneficial to other folks in the firm to replicate and share with their clients, but he doesn’t want to email the whole firm. An internal social tool gives him have a good place to share the document and notify others who subscribe to him or his workgroup that he created it, so no one has to reinvent the wheel or go digging in a massive fileshare. And the internal social feed is searchable and available on a mobile device, so coworkers can find the document and email it to a client while on the go. What’s also nice about social tools is they put the conversation in line with the client or opportunity data so your brain doesn’t have to think about where things go or where they are. We all know inboxes are cluttered and overwhelming, so you want to dismiss as much as possible and you delete emails just to filter out the noise. With the social conversation in the context of a client or pursuit via a social tool, things feel more manageable and contextual.

Another argument for social tools is that email is a bad way to do versioning since updates pass each other like ships in the night. Social tools make updates and edits into a trackable conversation, sometimes in real-time. And finally, if you need help, Outlook is a bad survey/helpline tool, while internal social tools boost your SOS signal to an active subscriber army of your coworkers, who can point you in the right direction and whose answers slowly build an ad-hoc internal knowledgebase, which leads to better, faster outcomes. 

From an external social perspective, you can open up these social tools to clients so they have limited access to reading and posting on specific topics (like a project), while still maintaining security fences around them. Also, there is some inherent security in the nature of the social medium that can save you from embarrassing yourself with a client, like the fact that you can’t forward posts and it’s pretty hard to accidentally reply-all. Using social tools with clients also feels like a conversation, so it’s less formal and can be great for collaboration in a more idea-driven or brainstorm-like environment. These tools also have updated UIs that make them more engaging than email and input your conversations with clients in the context of the project or your relationship with them since they often live on your client portal, and context is something email doesn’t really do. Simply having a client portal and collaborative social tools can really help distinguish your firm from others, and highlight a uniquely efficient way clients can work with you. The final thing to note about internal and external social conversations is that the data is easily and automatically archived on the Client record, which historicizes client interactions in a central system. This is not always the case with emails.

5. Proposal Generation:

For some professional services firms, proposals can be hundreds of pages long and include things like resumes, project references, and boilerplate text like leadership bios and company history. CRM has lightweight functionality around this natively, and is a solid repository for the data you’d use to create documents from the centralized information within it. However, in order to really create full on proposals, some integrations really should be built into tools like Word or InDesign. Ideally, these would leverage predefined templates for efficiency and take a step-by-step wizard approach, allowing you to also bring in documents and pictures from document management sources tied to CRM. CRM would allow you to search for relevant content for your proposal, and more generally update that content centrally in one place.

Those are just some common things professional services firms may wish to tackle in the third phase of their CRM implementation. There are plenty of others we’d be happy to help you explore and discuss. Hopefully, this series of posts helped you recognize how nuanced a CRM implementation can be, which is why a phased approach works best. Simply standing up a basic system and walking away is a recipe for wasted time, money, and energy, and won’t build goodwill with your users.  If you want to hear more about how to implement CRM for professional services firms using a phased approach, feel free to contact us.

Three Steps to CRM Success

Topics: CRM for Professional Services

You Gotta Know the Territory: Part 2

Today's blog post was written by Troy Oliveira, Principal Developer at Sonoma Partners.

In part 1 of this series, we briefly discussed the need for territory management and discussed how account teams could be a simple solution for solving your organization’s needs. But what if you’re looking for a solution that is a little more automated? A little more robust? Enterprise Territory Management might be the solution that you are looking for.

Enterprise Territory Management

If account teams were simplistic, Enterprise Territory Management falls on the exact opposite end of the spectrum.

Enterprise Territory Management is an incredibly powerful rule-based engine that allows for multi-level territory assignment that allows for companies to set up a highly structured model for assigning accounts to one or more territories.

Enterprise Territory Management (ETM) has several moving parts and can be daunting. The core components of ETM include the Model itself, Territories & Account Assignment Rules.

The Model

When setting up a territory model, the world is your oyster. First and foremost, the model is a hierarchy that can be utilized to describe relationships between the territories. Organizations are free to structure this hierarchy however they want; it can be flat with all territories on the same level or it can been very tiered breaking down territories into very specific segments. There is an overall maximum of 1,000 territories in the model, but that is the only system limitation. If your organization needs a model with more than 1,000 territories in the model, I would argue the model may need to be revisited to determine whether it is practical from a complexity and maintenance perspective.

Troy territory pt 2 1

Troy territory pt 2 2

Territories

Territories are the bridges that are used by the model for building out the relationship between accounts and user. Territories can be established in a manner that allows them to be completely isolated or, like the model itself, to be configured to inherit assignment rules from territories above them in the hierarchy.

Users are assigned to territories. Much like account teams, you can define roles for territory users. The users assigned will be granted the increased permissions to all accounts that are associated to the territory.

Troy territory pt 2 3

Account Assignment Rules

If territories are the bridge that relates accounts to users, Account Assignment Rules are the nuts and bolts that assemble the bridge and give it shape. Account Assignment Rules are filters that are applied against account data to determine which accounts should be selected as part of territory. The structure of these rules is very similar to the filtering used for List Views, Reports, and Workflows/Processes.

Troy territory pt 2 4

The assignment rules are then associated to territories. There are a couple things to keep in mind when thinking about associating assignment rules to territories. First, territories are not required to have an assignment rule; there might be territories in the hierarchy that merely show overall relationship or organization structure. Second, when multiple assignment rules are assigned to a territory, both rules need to evaluate as “true” for an account to be assigned to that territory. Last, depending on how extensive your model is, there may be scenarios in which accounts can be assigned to multiple territories.

How It All Works

Once a territory has been defined and activated, the administrator will need to initiate an initial assignment for accounts that already exist in the system (“Run Rules”). We recommend performing this initial assignment during non-business hours as Salesforce performs a great deal of heavy lifting generating the appropriate sharing rules to associate the accounts > territories > users.

Troy territory pt 2 5

As soon as the model is active, any new accounts will automatically be assigned to the appropriate territories. By default, once the account is assigned to territories, the relationship is set until the rules are manually run again. If your organization's territory model and assignment rules are set up in a way that requires accounts to move to different territories as data changes, that is possible with a little bit of configuration.

Troy territory pt 2 6

On each account page layout, you have the ability to configure the account to re-evaluate the assignment rules.  As an additional level of configurability, there is an additional option that is made available on accounts that allow users to signify that specific accounts should be exempt from re-evaluations of assignment rules.  This can be particularly helpful when there is potential that an account could change territories when there is an opportunity in progress so that the team working the opportunity can continue working it without fear that the account will be re-assigned.

Troy territory pt 2 7

Troy territory pt 2 8

Just like with account teams, Salesforce also provides the ability to filter the My Accounts to filter on "My Territories Accounts."   Similar to account teams, these filters are also available when building reports.

Troy territory pt 2 9

As with everything, there are some limitations involved with Enterprise Territory Management. The most common of these involves the definition of account assignment rules and fall into the realm of “practical” limitations. For example, if your model involves defining territories at a postal code level, there are limitations to the size of the account assignment rules that cause problems when trying to handle all possible postal codes. 

In Summary

Wow, a lot of detail here.  Let’s look at a condensed pros/cons list:

Pros: Cons:
  • Simple, native implementation
  • Limited to 1,000 territories
  • Point-and-click setup
  • Limits on assignment rule filter length
  • “My Territories Accounts” in filters and reporting
  • Does not always play well with bulk record processing
  • Territories automatically assigned on Account creation (can be re-evaluated on update)
  • A lot of overhead when running assignment rules

Now that we’ve looked at account teams and Enterprise Territory Management, what if neither option is 100% what you need for your organization?  Next time, we’ll take a look at custom solutions for territory management.

If you have any questions about Enterprise Territory Management or need help implementing your solution with Salesforce, please contact us.

Topics: Salesforce.com

Are You Lightning Ready?

Today's blog post was written by Nathen Drees, Senior Developer at Sonoma Partners.

Lightning ready

A year ago, Salesforce announced a new UI in Salesforce - Lightning Experience - aimed at rebuilding the desktop interfaces to provide streamlined access to the information sales reps most common uses. Since that time, Salesforce has continued to put significant effort into Lightning Experience, regularly adding updates and bug fixes to bring the UI in to feature parody with Classic. With the latest release (Winter ’17), the bulk of the features are now available in Lightning, and we expect the rest to be added very shortly.

Due to this influx of development and marketing efforts, we at Sonoma are seeing a majority of our new clients, and even some of our existing clients, embracing Lightning Experience as the standard UI they run their business on, and we expect that trend to both continue and intensify as time goes on. Extrapolating this trend into the future, it would seem we’re nearing a tipping point where more businesses will be using Lightning Experience as their default UI rather than Classic, which leads us to one question for our App Innovator partners: are you Lightning ready?

Riding the Lightning

Lightning ready 2Shortly after Lightning Experience was announced, Salesforce put in place a program for App Innovators to certify that their apps would work in Lightning Experience, and assisted them with marketing by adding a Lightning Ready sash to their AppExchange listing. While the requirements for being Lightning Ready has and continues to evolve, the core concept remains the same: make sure your app is seamless with Lightning Experience. Complicating matters is the fact that Lightning Experience continues to evolve as Salesforce updates it to support more features, meaning that you need to stay up to date with each release and ensure your app continues to work going forward.

You Can Do It, We Can Help

While this task may seem daunting at first, it doesn’t need to be, and we can help. We at Sonoma Partners have an in-house development and technical staff that can review your app for Lightning Compatibility at the code level, business analysts who know Lightning Experience from a configuration and reporting perspective, and QA staff who can ensure your app integrates seamlessly from an end users point of view. Should we find anything, the same staff can assist in gap analysis, any development or configuration needed to close the gaps, and end-to-end testing to ensure you pass your review with Salesforce the first time, with as little fuss as possible. We have experience working with App Innovators and know the business and the Salesforce security review process.

Need help determining if your app is Lightning ready? Just want a second set of eyes on it before you go in to the review with Salesforce? Want to talk about something totally unrelated? Contact us, and we can help.

Topics: Salesforce.com