Sonoma Partners Microsoft CRM and Salesforce Blog

Integrating MDR education and school data with your deployment

Sonoma Partners works with multiple customers in the education industry, and they frequently ask us about integrating MDR's school data with their CRM system. If you're not familiar with MDR, they provide the most comprehensive set of data about schools and school administrators throughout the United States. Most folks consider MDR data as the "gold standard" in the education industry. If your business works with schools, that means you have a fixed universe of customers to sell to. Consequently, having clean and accurate data about schools and their contacts becomes hyper-critical!

To help make sure that our education customers have clean school data in their CRM system, Sonoma Partners developed a process to update CRM with the latest and greatest MDR education industry data on a regular basis. The MDR data updates include detailed information about both schools (accounts in CRM lingo) and administrators (contacts). Some of the data points provided by MDR include:

School / Account Sample Data Points (this is not the full list, there are over 300+ MDR account fields and 85+ contact fields)

  • MDR District Enrollment
  • MDR District Classification
  • MDR District Grade Span
  • MDR District PC Computers
  • MDR DMA Code
  • MDR School Improvement
  • MDR School Type
  • MDR Technology Sophistication Index
  • MDR Student Enrollment
  • MDR Student to Computer Ratio
  • MDR Number of Classrooms
  • MDR Number of Schools
  • MDR Open Date
  • MDR Total Budget
  • MDR Total Number of Students
  • MDR Total Software Budget
  • MDR Total Technology Budget

Administrator / Contact Sample Data Points (this is not the full list, there are ~25 MDR contact fields)

  • MDR Status
  • MDR Title
  • MDR Last Name
  • MDR First Name
  • MDR Middle
  • MDR Name
  • MDR Preferred Title
  • MDR Gender
  • MDR Last Update Date
  • MDR Job 1
  • MDR Job 2
  • MDR Computer User
  • MDR Advanced Placement
  • MDR Years at School
  • MDR Years of Teaching Experience
  • MDR Highest Degree Level
  • MDR Email Address

 After integrating the MDR data with, the end users can view and access the data through the user interface and it will appear like the following:


MDR publishes refreshed and new data several times per year. Our integration updates all of the Account and Contact MDR data fields with each MDR refresh.  We recognized that our customers will be updating their Account and Contact data directly in Salesforce as well, and they may have more accurate information earlier than what MDR collects.  Therefore, we set up an exception process so if a user directly updated any of the MDR data fields, the integration will not update a manually modified data field with the MDR refresh for at least 6 months. Please keep in mind that we setup this exception process on a field-by-field basis.  For example, if a user updated the Phone number last month, but all of the other fields have not been updated in over 6 months, when the MDR refresh is run, all of the Account fields listed will be updated except for the Phone, which will not be overridden by the MDR integration.

We also recognized that you might NEVER want some fields overriden by the latest MDR data refresh (for example the email, Billing Address or Shipping Address).  To accommodate these scenarios we created a “Never Update from MDR” checkbox directly below each of these three data fields.  If you do not want your information overwritten, users can check this checkbox for the appropriate field.



Lastly (and maybe most importantly), MDR provides hierarchy data about how the schools rollup to districts, sub-districts, etc. This hierarchy data allows companies to perform rollup calculations of they well they perform within districts at an aggregate level. Consequently, companies could answer questions like "What's our total sales pipeline in District XYZ? How much of product X did we sell to sub-district ABC in the last 12 months?" This screenshot shows how we modeled the school hierarchy within


The MDR data integration with CRM provides our education industry customers with several benefits, including:

  • Accurate, cleansed account and contact data
  • Access to full universe of education customers based on standardized industry database
  • A repeatable data load process
  • Reduced need for manual record maintenance
  • Better information to make informed sales and marketing decisions

And yes, if you're curious, Sonoma Partners could help Microsoft Dynamics CRM customers setup a similar integration with MDR data!

Please contact us if you're interested in learning more about our experience integrating MDR data into your CRM system.

Topics: Microsoft Dynamics 365 Microsoft Dynamics CRM Salesforce

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

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

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

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

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

Retry Your Request

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

Recently we ran into an interesting issue while trying to create an application that could talk to Salesforce. We were using the Toolkit for .NET and had set up a connected application, but every time we tried to authenticate, we would receive the same error:

Nathen 1

Our application at the time was also pretty straight forward, just trying to log in and authenticate:

Nathen 2

After double and triple checking the credentials, and much head scratching, we finally found the solution. It turns out this was another case of the TLS 1.0 to TLS 1.1/1.2 switch coming back to bite us. Since .NET < 4.6 uses TLS 1.0 by default, we were using a now unsupported transport security protocol, and Salesforce was giving us the very unhelpful error message of “retry your request.” After telling .NET to use TLS 1.1/1.2, everything went smoothly:

Nathen 3

It turns out this has been found before (see this Github issue), but it’s relatively difficult to find this unless you already know what you’re looking for.

Just another day in the life of a Salesforce developer!

Topics: Salesforce

Making their Mark: Landmark's Adoption of Salesforce


Landmark Services Cooperative is a member-owned cooperative business with five divisions: Agronomy, Animal Nutrition, Energy and Retail Services, Grain, and their financial division, Verity Business Solutions. They provide agriculture products, services, and resources to over 15,000 members in communities throughout southern Wisconsin and northern Illinois.

When we first met Landmark in the fall of 2015, their divisions operated independently from each other when it came to customer data. Tim Dusek, Landmark’s Executive VP of Sales & Marketing, spearheaded this CRM project primarily to improve visibility into customer data and as a result, increase cross divisional sales and gain greater efficiency in their sales efforts.

By implementing Salesforce and increasing their investment in CRM, Landmark looks to revolutionize how their company operates.

We had the pleasure of sitting down with Tim a few weeks ago for a Q&A session on the progress of the project as Landmark continues to roll out their new CRM solution.

How have your employees taken to the new CRM system?

Tim: It’s been an evolving work in progress. When we first rolled it out, we gathered a lot of excitement around the new tool. We branded the project with a creative name – “Mark” – and did some internal marketing to spread the word, answer any questions in advance of the deployment, and get our sellers looking forward to the new and improved resource. That being said, there was a bit of resistance from some of the more seasoned sellers. I think they saw this to be more administrative burden with little reward with them. We continue to focus on the “What’s in it for Them” approach. We’re still working to appease this group of individuals, but ultimately, this is going to make our organization stronger and I think they’ll understand that once they get more familiar with the new system.

How will CRM improve your sales’ team effectiveness?

There are a lot of different ways CRM is going to be a tool for our sales team. We’ve built out functionality to access existing customer’s recent activity and basic customer information easily while in the field. All of this data is integrated with our ERP system, too. It’s seamless and efficient in a way that our processes never were before.

How do you plan to use CRM to better compete in your industry?

An edge Landmark already holds over our competitors is our ability to provide services across our different divisions. We have a few competitors who offer agronomy services but not necessarily animal nutrition. CRM allows us to channel this competitive edge to increase visibility across our departments. We ran into a situation recently where a client of the agronomy division wasn’t even aware we had a grain or animal nutrition division. We’d like that to never be the case.

What business problems are you trying to solve with CRM?

For us, it’s really a platform for centralized information. We have a lot of information kept in the brains of our very intelligent employees. We needed a way to spread this knowledge and make it accessible to all. By providing our employees with a single resource to hold information, we eliminate informal communication as a way of “storing data.”

Another key motivator to improve our CRM system was the cross-departmental visibility into accounts. As I mentioned, we never want someone to be missing out on an opportunity just because the client is unaware we have those capabilities here.

Why do you think your industry needs CRM?

I think customer retention is a huge motivator for the agribusiness sector – and most other industries who gain more revenue from existing than new clients – to get CRM. If you’re able to be more strategic in how you market to your current clients, you have a better chance of continuing to do business with them.

I also believe that technology in agribusiness has historically been behind. We need to evolve not only to rapidly grow our business, but to continue to attract the top talent in the industry who have come to expect this level of expertise.

Our thanks to Tim and Landmark for sharing their progress so far on their implementation. We look forward to reporting back on the project post-completion!

Are you looking for some CRM advice? We’re always happy to hop on a call.

Topics: CRM for Manufacturing Salesforce

Dreamforce 2016 Recap

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

After Dreamforce, I can’t wait for next year…

Having spent most of my life in the Midwest, I can be sure of a couple of things. One, I am always looking towards what is coming next (and used to being just a little discontent in the moment). In the summer, all we can think about is how hot and humid it is and that we cannot wait until it cools off. Dreamforce troy 1
In the winter, we complain endlessly about the cold and snow. Unfortunately, this is also a fact of life in how we view our daily work. I have always found the Salesforce platform to be feature rich and developer-friendly, but that doesn’t stop me from complaining about things like API limits and tools. Nor does it keep me from constantly looking for any hint of what is coming in the next release. Second, as an avid fan of the Chicago Cubs, I am very used to having to “wait 'til next year.” That is why I couldn't have been any more excited to go to Dreamforce and glimpse of what's coming in the upcoming releases. 

Going into Dreamforce last week, I didn’t know what to expect. This was my first Dreamforce, and despite all of the suggestions and disclaimers from those who had attended Dreamforce several times, I still wanted to see it all. Obviously, this isn't possible. Especially when you approach the conference through the looking glass of a consultant. Every session holds a treasure chest of knowledge and could lead to the next big breakthrough for one of your customers. It is all at once exciting and daunting at the same time.

Welcome to Trailhead

Dreamforce troy 2Being a developer by trade, I wanted to maximize my time and soak in as much as I could. This led me into the Trailblazer Forest (the whole conference was National Parks themed). I found this to be a great place to ask questions and see what was new in the ecosphere of Salesforce development.

Before digging into a couple of very specific things that I found to be of most interest, I would be greatly remiss without discussing a couple odds and ends.

The Lightning Design System is destined be one of the most powerful and underrated platform features. There, I said it. While today it may seem very trivial and strike many people as just being a way to make their custom development “look” like Salesforce, it is much more than that. By using the SLDS, developers will automatically get access to the ever-changing look and feel that is the Lightning Experience. Talking with some of the SLDS folks, looking at things like extended brand customization (beyond primary/secondary colors!) and a dark theme (up-vote that Idea here), it is evident that the roll-your-own styles are a thing of the past, or at least should be.

The Salesforce development tooling game in the community is strong. At Sonoma, we are partial to using Illuminated Cloud, but tools like The Welkin Suite, Salesforce DX (which I’ll talk about more below), and a redesigned IDE are all pushing each other. When that happens, all Salesforce Developers benefit.

Bulk API v2

The Bulk API is being completely re-imagined. While we won’t be able to see the true benefits and how it all shapes up in Spring ’17, I find it incredibly encouraging to know that Salesforce has recognized some of the pain points.  Dreamforce troy 3

Doubling the number of bulk job batches from 5K to 10K in Winter ’17 was a great step forward. But wait, there’s more. While increasing the batch limit is great, it still doesn’t help the scenario in which I need to use a small batch size in order to keep a job from taking too long to complete, but this will soon be a thing of the past. As they roll out v2 of the Bulk API, the focus will be on records, not batches, and we will be able to process up instead.

In Spring ’17 and beyond, look for ability to do bulk SOQL queries with relationships (no more manually correlating related data). 

All of these improvements are going to make a huge impact on data migrations and large scale integrations.

Salesforce DX

Two words…Command-line Interface. Not enough? Okay, fine. Let’s talk.

Dreamforce troy 4
Out of fear of being hyperbolic, I will go ahead and make another bold prediction. Salesforce DX is going to revolutionize the way that we develop for Salesforce. 

Having tools like the IDE, Illuminated Cloud, and heck, even the Developer Console, are great tools, they are just that, tools. They’re built on top of the platform and require a human to interact with the tool to deploy the code to an already existing environment. Salesforce DX changes all of this.

What does this mean? First and foremost, it means that continuous integration just got a lot easier. No longer do we need to write our own tools to extract or push metadata, to run tests, or even the need to manually create data. This will all be able to be done via command-line scripting. That means that regardless of whether you have a full-blown continuous integration environment, or if you lean more towards a series of batch files, you can automate your development. This also means that you can use whatever development tools that you like to edit your code.

Not good enough? How about the ability to create new temporary orgs on the fly? That’s what you get with scratch orgs. Imagine being able to create a new org, push the latest metadata and code, run your unit tests, and then upload a full data set to be able to demo the new whiz-bang application you just built. Now imagine all of that being 100% automated with the push of a button. That’s why this is revolutionary.

Of course, Salesforce DX is definitely in the “coming soon” stage, but if you can’t tell, I am really excited.

Lightning Component Builder

The switch to Lightning Experience came with the advent of Lightning Components. It also opened up the world of development to a much larger swath of the world’s development community. No longer are developers writing VisualForce, they’re writing HTML and JavaScript.

Lighting Base Components will allow developers to take advantage of some of the same controls that Salesforce uses to build the UI (no more re-creating picklist or text field functionality), and the Lightning Data Service will reduce the need for custom APEX as well as allowing for much faster page loads by sharing cached data.

While this is all great and good, the upcoming Lightning Component Builder takes it a step further. At Sonoma Partners, we have a fantastic group of individuals to direct our user experience development and quite often they are able to give us the full HTML look and feel, meaning that the developer only needs to wire up the data to existing HTML and run with it.

With the Lightning Component Builder, we will be able to take the prebuilt HTML (thanks, UX team!) and using a point-and-click interface, wire up the dataset and event, and have the tool build some of the custom JavaScript events with a few mouse clicks. I’ll admit it, developers are generally lazy. Anything that I can do to automatically generate code, I take it in a heartbeat. That is exactly what this does.

Let’s take this even a bit further. An Admin with some basic HTML and JavaScript knowledge will have the ability create some pretty rich, custom, data visualizations, all without the needing a developer to write a line of code.

That’s a wrap! Dreamforce troy 5a

Dreamforce was awesome. These are just snapshot of the great new things that are coming your way as a Salesforce customer and developer. I have made some pretty bold statements in this post. I stand by them. 

This is some pretty revolutionary stuff, not because features like this are earth-shattering or have never been done before, but because all of these features make the job of extending the platform easier.

When the “how” becomes easier and less time consuming, you can turn more of your attention to “what,” and the “what” is the thing that makes each implementation unique and powerful for your users.

New Call-to-action
Topics: Salesforce