Sonoma Partners Microsoft CRM and Salesforce Blog

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

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.


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.


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.



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.


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.


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.


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.


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.


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.


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.


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.


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


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


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.


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

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

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

It’s Not You, It’s Me: How to Best Break Up with Your Current CRM Partner

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

I've recently been working with two different clients who were both in a situation where the relationship with their current partner had soured. In listening to these clients, I was shocked to realize it took a final straw for them to start seeking a new partner. So many problems had happened throughout the relationship, but they had waited, trying to stick with it and work it out. As an outsider, I initially thought, what took them so long?

But the reality is – just like in our personal relationships – breaking up with your current CRM partner is hard.

The most obvious reason for this is money. At some point, you've invested so much money into the initiative with the partner, you just want your money's worth. The second is that now you feel jaded. How do you properly vet the new partner? You feel like you just got burned and are unsure of how to move forward. For help on that, we have some tips here.

Once you've made the decision to end the relationship with your current partner, there are a few things you should do to protect yourself:

  1. Don't let on right away that you are going to end the relationship. Letting them know can either change nothing or make the situation worse. Your current partner could just focus on salvaging the relationship or write you off and become unresponsive. Either of these two things will make the next steps harder, so its best to keep a lid on it.

  2. Get access to the codebase and ensure you are getting daily updates. Review the code internally, or if you have found a new partner, have them review it. Not having this could mean starting from scratch with your new partner. You also want to have assurances that the outgoing partner is staying above board as they roll off. Getting your new partner involved in the review helps ramp them up and drive the discussion for the next two points.

  3. Review your documentation. Determine what hasn't been done and what was changed. Update the documentation accordingly. This documentation will help you prioritize what needs to be done next. While its fairly easy to determine that a whole feature is missing, its harder to determine if the execution of the features was to spec. Once you have the documentation updated, this can also be used by your new partner to ramp up.

  4. Start asking questions. What tools are being used? What environments are setup? What servers are we using and what are they being used for? Has the partner used any of their own IP and who owns it? Your outgoing partner did all of that work FOR YOU. You should know all the ins and outs of what they are using in order to do that work. If they used something and you don't know about it, it may cause issues down the line. Also, use this as a way to track what they have access to, so you can turn of that access when they are gone.

  5. Once you've selected a new partner, let the old one know you are going to end the relationship. Schedule an end date and some knowledge transfer meetings. Ideally, get your new partner on these meetings. The goal is that these meetings will be fairly quick, because you have done steps 2-4, so there shouldn’t be too much more to learn. Your old partner may not agree to these and just want to let you go on your way, but you should be confident that you can.

It’s not easy to find the right partner, nor is it easy to end a bad relationship. There are steps you can take to protect yourself and help facilitate the transfer to your new partner.

And, as always, we’re here to help.

Topics: CRM Best Practices

Migrating Data from a MySQL Database

Today's blog post was written by Rob Jasinski, Principal Developer at Sonoma Partners.

Recently, we had a need to migrate data for a customer to Microsoft Dynamics CRM, but the data was located in a MySQL database. We have many tools, applications, and interfaces that rely on the source data being Microsoft SQL Server, so ideally we like to convert the data from a different database platform to SQL Server whenever possible. Since MySQL is open-source and considered the second most popular used RDBMS (according to Wikipedia), we use this platform more than others.

To convert a MySQL database, you’ll need to first have MySQL installed which can be downloaded from here. Then, you’ll need to install the SQL Server Migration Assistant tool. I won’t go through step-by-step on how to use this tool as there is a good blog here to get started. Instead I will go through some of obstacles I had and how I resolved them.

Restoring a Backup of the Database to Your MySQL Database

When I loaded the SSMA tool, I had issues connecting to the MySQL database. I finally had to completely uninstall the MySQL ODBC driver and re-install it to finally get a connection to work. For the SQL Server connection, SQL Server agent needed to be running so it was started. Next, check the target schema. I’m not quite sure how this is defaulted, but it was pointing to the wrong SQL database. I didn’t notice this at first and had to change it manually.

Before the data can be migrated, it must synchronized so the tables are created on the destination. The “How To” blog states it’s under Tools, but I didn’t see it there. I finally found it in the SQL Server metadata browser window, if I right-clicked the destination database, synchronize was an option.

Finally, when I tried to migrate the data, the process would start then the application (SSMA) would just suddenly close after about a minute or two. I retried several times even after a server restart and the same issue continued. After some research I found a message post to try and set the affinity of the application (SSMS) to just one CPU. After I tried that, it worked. All the data from MySQL was migrated to the SQL Server database.

Once we had the data migrated to SQL Server, we were able to use our common data scrubbing tools to clean and migrate the data into CRM.

Topics: Microsoft Dynamics CRM

You Gotta Know the Territory: Part 1

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

When I was a child, one of my first exposures to the genre of Broadway theatre was The Music Man, in which a brash salesman named Harold Hill was beguiled by the traveling salesman community for not knowing the territory. His story is not unlike that of many salespeople in companies everywhere.  He would roll into town (a prospect) and sell what he could, not fully understanding what he was selling and when he was done, he moved on to the next town. His selling strategy involved getting in and getting out - once he closed the deal, the customer was left on their own to figure things out. There was no hope or even attempt at repeat business or customer follow-up.

Given that you’re reading this post, I can only assume that you have figured out by now that this model of sales is not sustainable and that building a relationship with your customers is an important part of your daily business and sales practices.

One of the components that we help our customers wrestle with in almost every customer engagement is around the idea of territory management.

Very quickly we learn that everyone puts different meaning to the concept of territories, ranging from the strict rules to "parlay" (…more of a guideline, really). Some have singular salespeople as the overseer of the accounts in a territory while others work in teams or have multiple product lines that service the same territory. The good news is that the Salesforce platform provides some really flexible options for being able to manage territories, and lucky for you, that’s the topic of this post.

Sharing is Caring

In this series of posts, I will walk you through some of the high level features, benefits, and drawbacks of the three territory management methods that we work with on a daily basis: account teams, Enterprise Territory Management, and custom solutions.

Account Teams

If we start with the premise that every user has the ability to see every account, and we have multiple people who need to be able to work the account and make necessary updates, create opportunities, etc., account teams are by far the easiest form of territory management that Salesforce provides. 

From a bare-bones perspective, account teams are a list of users who are added on as an ad-hoc basis to each account and as a result, are extended additional permissions for the account and related objects.

Troy territory 1

Don’t let the simplicity of account teams fool you - they are an incredibly powerful tool for extending permissions to accounts and extend abilities that would normally only be available for account owners. Account teams also provide your users flexibility in creating account views. Instead of only having access to “My Accounts," they now have access to filters based on “My Account Teams Accounts,” allowing users to see a list of all accounts which they “own” by being part of the team. This functionality also extends to reporting.

Troy territory 2

Account teams become even more powerful when combined with the concept of default account teams.  Default account teams can be set up at a user level and when an account is assigned to a user, their default team is automatically added to the account. For example, as a customer relationship manager, I have a set of account managers and sales reps that I work with on all of my accounts, I can setup my default account team to include those users and when an account is assigned to me, my team automatically gains access to the account.

Troy territory 3

Beyond simply providing access, account teams also provide the ability to define the user’s role on the account. Account team roles are a great way of distinguishing what the user does for an account. For example, in my scenario of wanting to talk to sales reps who are selling a product that I am having trouble selling, I can quickly determine who the sales rep is for an account that recently purchased the product by looking at the account team and finding how who is in the sales rep role. Another great example of using roles for account team members is when your company has multiple business lines. Organizations can set up a role for each business line and by notating who the salesperson is in each business line, you can provide feedback for purposes of cross-selling when you hear that the customer is interested in a product that falls outside of your business line.

If it sounds too good to be true, it might be. Because this is the most simplistic option for managing shared ownership, there are some restrictions. The very base component of account teams is around providing access, not determining how the account teams are assigned. The overall process of adding account team members is manual and ad-hoc. Even when using default account teams, you will still need another process in place to handle the initial assignment.

Another potential pitfall with account teams is that when the teams are shown on the page layout, anyone who has access to edit the account also has the ability to add users to the account team, though they do not have the ability to extend access levels. This can be specifically problematic when your organization has gone to great lengths to build workflows and processes to ensure that specific people are added to specific account teams. Ultimately, this leads to a discussion around removing visibility into account teams which reduces transparency.

In Summary

That’s a lot of information about account teams. Let me distill it down into some simple pro/con lists.

Pros: Cons:
  • Simple, native implementation
  • Manual process
  • Point-and-click setup
  • No relationships
  • Quickly add team members to accounts
  • Account team members can add new team members
  • "My Account Teams" in filters and reporting
  • Default teams for record owner

Next up in this series is enterprise territory management.

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

Topics: Salesforce