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

Redefining a 360-Degree View of Your Customer

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

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

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

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

Imagine the following scenario of a customer hierarchy:

Kyle d 1

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

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

Build Steps

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

1. Create Account Record Types

Kyle d 2

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

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

Kyle d 3

3. Create an Account Page Layout for Each Record Type

Kyle d 4

4. Map Account Page Layouts to appropriate Account Record Types

Kyle d 5

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

Kyle d 6

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

Kyle d 7

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

Kyle d 8

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

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

Kyle d 9

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

Kyle d 10

Kyle d 11

Kyle d 12

Kyle d 13

Formulas:

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

Testing

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

Kyle d 14

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

Holding Company:

Kyle d 15

Customer B:

Kyle d 16

Customer C:

Kyle d 17

Division 1:

Kyle d 18

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

Kyle d 19

Requirements/Other Considerations

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

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

Summary

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

Topics: Salesforce

You Gotta Know the Territory: Part 2

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

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

Enterprise Territory Management

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

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

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

The Model

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

Troy territory pt 2 1

Troy territory pt 2 2

Territories

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

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

Troy territory pt 2 3

Account Assignment Rules

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

Troy territory pt 2 4

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

How It All Works

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

Troy territory pt 2 5

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

Troy territory pt 2 6

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

Troy territory pt 2 7

Troy territory pt 2 8

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

Troy territory pt 2 9

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

In Summary

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

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

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

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

Topics: Salesforce

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 Force.com 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

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 Force.com 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 Force.com 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 Force.com 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 Force.com 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 Force.com 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 Salesforce.com implementation unique and powerful for your users.

New Call-to-action
Topics: Salesforce

Enough Chit-Chatter: Replacing Chatter Desktop

Today's blog post was written by Corey O'Brien, VP of Development at Sonoma Partners.

The Need for Change

Lately, Salesforce has put Chatter Desktop into maintenance mode.  The last few updates have only consisted of replacing old certificates – just enough to keep it running.  In addition, it is built on top of Adobe AIR, which has its own runtime that frequently prompts users to update it.

Defining Our Vision

With that in mind, several of us set out to build a new desktop client with the following high level goals:

  • Support for Windows and Mac
  • Modern and clean design
  • Add features missing from Chatter Desktop
    • Searching posts and comments
    • Indicate which posts are read/unread
    • Support for polls (both creating  and voting
    • Allow multiple feeds to be opened at once
  • Support configurable popup notifications
  • New versions should auto-install seamlessly
  • Does not need to be mobile friendly (Salesforce1 is a great mobile client)

Design wise we drew a lot of inspiration from TweetDeck, which allows multiple columns to be viewed at once, or it can be collapsed into a single column view.  Below is an example of the current working version.

image

Bringing the App To Life

We decided to build the app as a Chrome App, which would help solve the cross platform and auto-updating goals.  The app is written in JavaScript and uses React, Redux and several other frameworks.

One of the challenges we faced building the application was keeping the content up-to-date, without hitting the Chatter API usage limit.  This problem was more difficult as users added columns.  To address this, we first added code to detect when the user was idle (not using the mouse or keyboard).  During idle periods, we wouldn’t poll for changes.  In addition, we started only auto-polling the main News column (which is required), only when that feed had an update would we auto-update the other columns.  With these changes we have been able to poll every minute without running into usage limits.

Future Roadmap

With Google’s announcement to discontinue support for Chrome Apps on Windows and OS X, we’ve started to look at repackaging the app as an Electron app.  Most of the code should be portable, but it will require a server for simple installation and distribution.

There are also a lot of little features that haven’t made their way into the application yet, like editing and deleting posts, but due to the use of modern frameworks those are fairly trivial to add.

Final Thoughts

This has been a very rewarding journey so far as it has gotten us more exposure to the Chatter API and HTML/JavaScript desktop application development.  In addition, end users have been thrilled to have some fresh Chatter features back on their desktops and the reviews have been glowing.

Are you a Sonoma client and interested in trying it out?  Talk to your team about getting early access!

New Call-to-action

Topics: Salesforce

Winter is Coming: What's New in the Lightning Experience with the Salesforce Winter '17 Release

Today's blog post was written by Caitlin Pfeiffer, Principal Consultant at Sonoma Partners.

The Winter '17 release notes are published, preview sandboxes have already been upgraded, Dreamforce is next week… all signs that (for my fellow Game of Thrones fans) "winter is coming." Salesforce has three releases each year, but in coordination with Dreamforce, the Winter release always seems to have a lot of big new features.

The Salesforce Winter '17 release is no different - there are lots of exciting new features to look forward to.

NOTE: Don't have time to read the 447-page release notes document? Check out this Top Features reference that highlights some of the big new features coming with the Winter Release.

Winter '17 comes with too much to cover in a single blog post, so this article will focus on some of the new features coming in the Lightning Experience. The Salesforce Lightning Experience was launched in last year's Winter release. Even though throughout the past year more and more feature are now supported on the Lightning Experience, a lot of my clients still were missing a few critical features necessary for them to make the jump. In this release, we're seeing some big enhancements to the Lightning Experience that I think will allow for many more companies to start using it. This blog post will highlight a few of my favorites.

What was once in Classic is now in Lightning

In this release, you'll see a lot more support for features that previously were only available in Salesforce Classic. To name a few:

  • Horizontal Tabs: Lightning currently has an icon bar that runs vertically down the left-hand side that you can expand and collapse (this model was very similar to the Salesforce1 navigation). However, with Winter '17, Lightning is moving back to the "horizontal tab" UI that we all know and love from Salesforce Classic.

Winter 17 release 1a

Winter 17 release 1b

I believe this change will make it easier for Classic users to transition over to the new Lightning Experience. In addition to the familiar design, this new navigation feature also allows for quick access to recent records and list views without having to navigate to the tab first.

Winter 17 release 2

  • App Branding: This sounds like a simple one, but most of my clients really like to be able to configure their Salesforce environment to align with their brand. Lightning users are now able to use their own company logo and company color.
  • Inline Editing in List Views: Inline editing in list views is often one of the favorite usability features of Salesforce Classic and is now finally available in the Lightning Experience. Although this is a big jump in the right direction, there's one caveat I must point out: inline editing in Lightning only allows you to edit one record at a time; it does not allow you to apply your edit to multiple selected records as you can in Classic. I'm hoping to see mass editing in List Views soon!

Winter 17 release 3

  • Quotes and Contracts: I'm glad to see that there is now Lightning Support for Contract but REALLY excited for Quotes in Lightning. Quotes are used by a lot of my clients, and this was a feature that was preventing a lot of people from moving to Lightning. You can now create Quotes & Quote Line Items, sync Quotes, and create Quote PDFs.
  • Adding Campaign Members from Contact/Lead List Views: Campaigns have been supported in Lightning since Spring '16; however, you only could add campaign members individually or through the new import wizard. For companies that manage large campaigns, not being able to add Campaign Members from Contact/Lead List Views was a big inefficiency.
  • Other Notables: A few other noteworthy notables that I'm excited to see, the Lightning Experience now supports:
    • Help Text
    • Collapsible sections on page layouts
    • Save & New functionality
    • Product Schedules
    • Ability to manually edit Opportunity Probability

What New in Lightning and Only Lightning

In addition to adding more "Classic" features to the Lightning Experience, Salesforce continues to show that Lightning is the future UI they are investing in by adding some new features that are only available to the Lightning Experience. There are a lot more than what I’ve listed, but here are a few of my favorites.

  • Kanban for Leads, Contracts, Campaigns: In my opinion, the Kanban List View is one of the huge differentiators for the Lightning Experience and it’s now available for Leads, Contracts and Campaigns. Support for all of these objects is great (and I hear that support for all objects, including custom objects, is coming in the roadmap… safe harbor), but support for Leads is definitely the use case that I can see most companies being excited about. Lead Qualification processes are often just as important as Opportunity Sales Processes, so it’s great that Lightning users now can use this power UI for managing leads.

Winter 17 release 4

  • Edit directly in Kanban: Currently, Kanban is built for moving Opportunities between Sales Stages quickly and easily. But if you want to make additional updated to Opportunities in the Kanban list view, you have to drill into each Opportunity to make those edits, causing a lot of clicks and navigating back and forth. In the next release, you can edit records directly from the Kanban view without having to leave that view. This is going to make Kanban all the more powerful!
  • New Feeds for Contacts: Similar to Account Insights (which will be updated to being called Account “News” in Winter), you can now see a News feed for your contacts. With this feature, Salesforce has also embedded a great crowdsourcing feature, we you can provide feedback on if you feel like a News article is relevant or not, which will only help Salesforce improve this functionality for all users.
  • App Specific Page Layouts: Currently, Administrators have the ability to configure different page layouts for different Profiles and Record Types. In Winter ’17, Salesforce is adding an additional dimension to provide even more granularity for what page layouts are used in the Lightning Experience. You will now be able to configure different page layouts for different Lightning apps as well. The main use case here is to allow companies to create a much more tailored experience within an app. For example, you can create a Sales app that will show the key sales fields and lists Opportunities as the first related list on the Account page layout and also have a Service app that will show Cases and Service Contracts as the first related lists on the Account page layout. One word of caution: while this provides companies with a LOT of flexibly, it also adds another layer of complexity to maintaining your Salesforce environment. I would recommend that you consider the use cases that would warrant enabling this functionality carefully to make sure that the value will outweigh the additional maintenance of more page layouts.

Have questions on how or if you are ready to move to the new Lightning Experience, Sonoma Partners can help (contact us). 

Three Steps to CRM Success

Topics: Salesforce