Accounts in Dynamics 365 “represent a company with which the business unit has a relationship.”
This can include customers, prospective customers, vendors, competitors, or any other type of company. [Insert tippy tip about renaming account entity]. Account is one of the most important entity, as almost all other entities are related to account directly or indirectly. Accounts are the potential customer on opportunities, the customer on cases, orders, quotes, and invoices. And along with Contacts, they put the C in “CRM.
Let’s review the account form to understand what is available by default.
The default header includes annual revenue, number of employees, and owner. Given that the header is always visible, unless these are the most important fields to you, you may want to replace some of these fields with more relevant information.
The summary tab includes the most frequently accessed details about the company.
- Account information identifies who the company is along with phone number, address, website, and parent account. Frequently the account number field is added to this section if your company uses account numbers to refer to clients (for example, when CRM is integrated with ERP).
- Activity and social pane is a common component of all forms for entities enabled for activities and notes.
- The third section includes a link to the primary contact (person) for the company, along with other methods of contact, including email and phone. This section also presents related child entity data, giving users a 360 degree view of company relationships, including contact associated with the company, recent open sales opportunities, cases, and entitlements.
Note that in the image above there appears to be a lot of empty space. As additional notes and activities are added to the account, the form will look more complete. If you don’t use any of these entities, you can remove these subgrids or replace with more relevant information (such as related quotes or orders)
The details tab includes less frequently accessed account information. The details tab is typically infrequently accessed, and may be important only to a small subset of users, but it is important information.
- Company profile includes identifiers for Industry and SIC code, as well as public/private ownership.
- Marketing reflects marketing related details, such as what was the originating lead, last date the account was included in a campaign, and whether or not marketing materials should be sent to the company.
- Billing captures the billing and financial details for company financial transactions. The most important field in this section is currency, as it determines the default currency to be used for related quotes, opportunities, orders, invoices, or any other related child entity with currency fields that is related to the company. The other fields such as credit limit and payment terms are useful reference points, and do set properties on related quotes, order, and invoices. If you integrate CRM with your ERP, the financial system typically maintains these properties.
- Description is a long text field for a description of the company. This can be helpful for a sales representative to read when he or she is new to familiarize themselves with the company, and many Dynamics 365 customers copy the description of a company from their website to populate this field; however, you want to be careful, as this information can get outdated, so it is recommended not to rely too heavily on the account description form if you don’t regularly update it.
- Contact Preferences record the communication preferences of the company, including preferred contact method and whether or not communication via email, bulk email, phone, fax, or mail are allowed. Some of these fields carry special properties in the system, for example, if an account or contact are set to not allow email, the system will not allow an email to be sent from CRM to or regarding that customer. If you set phone call to “do not allow,” the system will not allow users to include the customer in a phone call. Note that this does not actually prevent the user from calling or emailing the company or contact, it just prevents these types of records to be created in the Dynamics 365 system. Also note that this may not be sufficient to comply with certain anti-spam laws to prove consent to be contacted.
In an effort to simplify the Account form, Microsoft does not include every account field on the form. The following are frequently used system fields that exist in the account entity but are not included by default on the form. You may want to add these fields to the form if they have value to you:
- Account number: A text field and is frequently used when integrating Dynamics 365 with your ERP or financial system.
- Address 2: Dynamics 365 includes 2 addresses on the account entity (and as many as you want more via the “more addresses” entity). By default, only address 1 is displayed. If you have two primary addresses for your customers (such as mailing and street address), add address 2 and define for which purpose each address should be used (such as street address in address 1 and mailing address in address 2).
- Relationship Type (customertypecode): Option set used to classify companies based on the type of relationship that they have with you. Need to identify whether a company is a customer, prospect, competitor, or vendor? Use relationship type and update the option set with the appropriate values.
- Category: Option set capturing whether the customer is “standard” or “preferred”
- Classification: Option set indicating the potential value of the customer account based on the projected return on investment, cooperation level, sales cycle length or other criteria.
- Modified By and Modified On: System fields indicating who last updated the record and when it was updated. If this is important detail to see on the record, you may want to add these fields to the form footer.
- Status and Status reason: indicate the status (active/inactive) of the record. Typically users can tell if an account is active or inactive based on whether the record is editable; however, if you integrate your accounts with another system (like ERP) or you don’t grant users security permissions to update records, they may see active records on read-only forms, so adding the Status or Status Reason to the account form may be helpful in identifying the active state of a record.
Deploying account management
As you start using Dynamics 365 for account management, there are several questions that you will need to answer as you build your account data in Dynamics 365.
Where will my data come from?
Are you migrating company data from another system? Importing it from a spreadsheet? Or is the data integrated and synchronized with another system
If you are integrating Dynamics 365 accounts with another system (like ERP), which system will be the “master” for integrated records? For example, if you are integrating with Dynamics AX, you probably will want AX to be the “owner” of customer records, given that the ERP controls financial transactions and order fulfillment. For integrated company records, you will want to lock down primary account fields (so that users don’t overwrite integrated field data values).
But you may have other types of companies that you work with that are not in the ERP, such as prospective clients that have not ordered anything yet. If Dynamics 365 will be used to manage sales opportunities with leads and prospective customers, you will want to give salespeople permission to update fields like company name and address on prospective customer records, but lock these fields down on client record.
A common approach for controlling updates to customer records is to populate the Account Number field in Dynamics 365 accounts with the identifier for the company in the master system. Then, via a business rule, lock the fields that should not be updated by end users if the Account Number field contains data.
With this approach, salespeople will have the flexibility to create and update prospective client records while protecting master client data.
What’s in a name?
The name of company records is very important, the company name is what you will use to search for companies that they work for, and the name field appears in any lookup field that references a company (such as the “Regarding” field on activities and the parent customer field on contacts).
The “name” field on accounts should contain the name which your users use to refer to the company. Sometimes the commonly used company name is not the same as the legal name of a company. For example, say you work with a large retail chain with multiple locations—you will want to name the locations in a way that users can easily identify which company location they are working with. You may want to add an identifier such as city name to the company name to make it easier for users to identify the correct account.
If the common name of the company is different than the legal name, and you are integrating Dynamics 365 with your accounting system, you may want to add a secondary name field. That way you can use the name field for the “friendly” name that users refer to the company and also have another text field for the official legal name for the integration.
Who is the parent?
Another planning point is the parent account hierarchical structure. If you work with large companies with multiple locations, you will need to decide how the hierarchy will be modeled in Dynamics 365. Should you create a company for each level in the hierarchy, or should you flatten it out? One rule of thumb is you should create a company for each level at which somebody can buy something or each level where you have distinct people that you work with. So if you work with a manufacturing company with a corporate headquarters, two divisions, and different locations for each division, you may create an account for each location, a parent account for each division, and have each division account parented by a record for the corporate headquarters.
What you need to know about Parent accounts
- Parent account is a self-referential 1:N relationship between accounts. A company’s parent is visible via the Parent account lookup field on the account form.
- The relationship hierarchy can be viewed by clicking the hierarchy visualization button on the upper right side of the form.
- Activities on accounts roll up to the activity view on their parent accounts. If you have a scenario where you have different sales reps working with different locations of a company and you want to be able to monitor what is going on at all locations, you don’t have to open each company to read the activity history—just open the parent account and look at the activity view.
How should I classify my accounts?
Given that many different types of companies can reside in the account entity, it is important to classify your account data so that users can find what they need to find and different types of companies can live together peacefully.
Why not just separate different types of companies into different entities?
You may be tempted to say “instead of adding different types of companies into the same entity, I will create custom entities for customers, prospect, investors, advisors, and vendors.” While you can do this, it is typically not advisable for the following reasons:
- Some companies will have multiple types—you may have a company that you sell products to from which you also purchase components used in your manufacturing process. If you separate them to different entities, you will duplicate data.
- The standard account/contact relationship has special properties—address values map from account to contact when contacts are created, the company relationship on the account form points to Account entity, and the account name synchronizes to Outlook contacts with the standard exchange contact synchronization. If you use separate relationships between contacts and other types of company records, you will limit this system functionality for contacts related to other types of companies.
- Account entity has standard support for multiple addresses per company. While you can add custom address fields to custom company entities, you cannot relate them to the customer address entity, so you will not be able to leverage the standard “more address” functionality.
Standard classification fields
Dynamics 365 includes several standard classification type fields:
- Relationship type
Additionally, custom company classification fields may be added to Dynamics 365 accounts.
How should I segment my Accounts?
In the previous section we talked about classifying accounts. Classification answers the question “who are you and how are you related to me?” Segmentation answers the question “what is the value of this customer and how closely aligned with them are we?”
The frequently sited Pareto Principal (aka the “80/20 rule”) states that 80% of your effects will come from 20% of the causes. When applied to sales, some people have observed that 80% of the sales comes from 20% of the customers.
When you sell a product or service, to be most effective, you must identify the highest value customers so you can focus your limited sales resources where the outcomes will be most profitable.
There are multiple strategies for client segmentation. An effective customer segmentation strategy should answer the following questions:
- What is the value of the customer to us? This can include potential revenue, but also other more intangible value, such as the value of having a well known customer in a target industry.
- What is our value to the customer? Are they in our target industries? Do we fit within their strategic goals?
- What is the client’s future potential? Is their business growing or shrinking? A medium sized customer with rapid growth may be more valuable than a larger size customer whose market share is declining.
When the client is high value to us and we are high value to the client, these are the companies that we are strategically aligned with and should focus the most sales resources on them.
Client Segmentation approaches
Strategic account management (SAM)
One of the oldest forms of account segmentation is Strategic Account Management (SAM).
Strategic account management is defined by the Strategic Account Management Association (SAMA) as “is a company-wide initiative in complex, highly matrixed organizations which focuses on building strong and mutually beneficial relationships with a company’s most important customers and partners.”
SAM segments clients using the following tiers:
Tier 1 High value to the vendor and the customer. These are the accounts that get tagged Key or Strategic.
Tier 2 (A) High value to the vendor, but low value to the customer. These accounts need care and the vendors will look for ways to improve their value to the customer.
Tier 2 (B) High value to the customer, but lower value to the vendor. The vendor must learn how to take more revenue and profits, or other non-monetary value out of these accounts
Tier 3 Lower value to both the customer and vendor; classic transactions accounts. Good to have, but not appropriate for a strategic management approach. Most companies manage these accounts through their customer service department. Often the customer will call the customer service team looking for an add on or enhancement. It’s growth just by being there; we call it catching raindrops.
Another common segmentation strategy is “ABC Analysis.” This is generally more simple than SAM, but still provides a useful framework by which customers and potential customers can be segmented.
A: Most valuable customers by revenue or strategic importance.
B: Average value clients that have the potential to get to segment A.
C: Low value clients with minimal future potential business or alignment with strategic goals. The least amount of sales resources should be dedicated to this group, or sales should be automated for this segment.
The segmentation methods identified in this chapter have been traditional manual segmentation methods. New technology is making client segmentation much more precise, with tools like machine learning automating segmentation based on rules and refinement based on actual sales data. Microsoft provides a segmentation engine called Dynamics 365 for Customer Insights that works with Dynamics 365 Customer Engagment.
Why segment clients in CRM?
You will likely have different sales reps or teams focused on different client segment tiers. For example, a national sales team focused on A accounts and an inside sales team focused on B accounts. By storing the client segment on the account entity, you can filter company views based on client segment and automate account assignment based on the segment of the client.
This will empower your sales representatives to focus their time on the most strategically important customers.
How should I assign my accounts (territory managements)?
There is not one right answer for how you should handle record ownership. There are multiple account assignment strategies. Some common examples:
- Geographic territories: zip codes assigned to territories
- Industry territories: users or teams specializing in certain industry verticals
- Segment territories: territories separated based on customer segment
- Team selling: Multiple people own the account
- Open accounts: nobody owns the account, or sales representatives are salary based.
However you assign your accounts, the following are some recommendations for successful territory management in Dynamics 365.
- Consider the security implications—do sales representatives need to be limited in what company records they can see or update? If the answer is yes, you will want to assign the sales representative’s accounts to the sales representative, or to a team on which the sales representative is a member. But before you lock everybody down to only see their own stuff, ask yourself if this is driven by a legitimate business requirement, or if it is driven by fear and mistrust of your employees. Legitimate security restrictions are ok, but excessive restriction for the wrong reasons can negatively impact user adoption and data quality (when multiple reps create prospect records for the same company). See the Security chapter for more security recommendations.
- Dynamics 365 includes a territory entity located in Settings>Business Management>Sales Territories. There is a lookup to territory on account (although it is not displayed on the form). This can be used to build a territory structure and relate territories to accounts.
This is nice, but basic. The territory entity does not have any special system properties, other than providing a lookup for territory. There is no automation between the territory manager and the owner of accounts in territories. It does support adding multiple members to the territory, but these members are not granted any permission to the accounts in the territory.
- Make the territory entity better: The following recommendations will increase the usability of the standard Dynamics 365 territory entity:
- Add a parent territory self referential lookup if you have a territory structure.
- Add a subgrid of accounts in the territory and a subgrid of territory team members to the territory form.
- If the territory manager should be the owner of all of the accounts in the territory, add a process like a plugin to automatically assign accounts to the territory manager when the account is added to a territory or the territory manager assignment changes.
- If you use geographic/zip code based assignment, create a custom entity for zip code, replace the standard account address 1 zip code field with a lookup to the custom zip code entity, and add a 1:N relationship between territory and custom zip code entity. This will enable to you automate the assignment of accounts to territory based on zip code much easier, and also make territory realignments much easier. If you do this, be sure to map the custom zip code lookup field to the standard zip code text field, as that filed is linked to the Customer Address postal code field, and also maps to contacts when they are created or synchronized with Outlook contacts.
- Automate it. If your territory assignment follows a set of rules, these can be automated so that when a new account is added, it is assigned to the correct territory automatically, without an administrator having to do anything. This can be driven by several methods, including workflows, plugins, and batch integration jobs.
- Make it easy to administer. Over-engineered or overly complicated territory logic can sometimes break down over time. The leading reason for this is processes that are difficult to administer. If your CRM partner goes away or your CRM administrator gets hit by a bus, the territory logic should be easy to administer so that it is maintained over time.
- Make it easy to update. I have seen many territory designs that are very cumbersome to change when a territory assignment changes. For example, if your territory is driven by postal code, instead of putting the territory on the account, create a table of zip code records, and associate the territory with the zip code. With this approach, changing the territory of accounts in a certain zip code only requires update of one record, rather than updating hundreds of account records.
What if multiple people “own” accounts?
If you have multiple people who are responsible for an account, you will probably want to use some of the team options available in Dynamics 365. Teams are handled in greater detail in the Security chapter of this book, but we’ve included a summary of the main options in this chapter.
- The same group of people manage the same accounts: If Janet, Jim, and Pat work together on all of the same accounts, owner teams are the way to go. You can define a static team with set members and assign all of the accounts managed by the group to that team.
- Each account has teams with different members. Sometimes teams are assembled ad-hoc based on factors such as skill or certification required and market segment. In this case you would probably want to assign the account to the lead representative and then add an access team to the account and assign the rest of the ad-hoc team to the access team.
What if nobody “owns” the account?
In some cases, there is no clear owner for an account, for example, in a bank where anybody can help the company with their questions. In this case, remember that all company records in CRM must have an owner, but that doesn’t necessarily have to mean that the designated owner has special privileges on the record. Alternatively, you may decide to assign the accounts to a defined system administrator or service account, or assign them to the team for the business unit, granting all users in the business unit ownership over the account.
Even if nobody really “owns” the record, one consideration that you may want to think about is that ownership of records determines what appears in the “My Accounts” view. If you assign all accounts to the business unit team, all users in the business unit will see all accounts in the “My Accounts” view. For this reason you may still wish to determine a primary owner for account records.
How should I manage company addresses?
In Dynamics 365, there are two addresses on the account entity (although only one is displayed on the form by default). Additional addresses are located in the “More Addresses” entity, available from the Dynamics 365 navigation menu.
Even though addresses appear in multiple places, Dynamics 365 stores all addresses in the Address entity. The Account entity address fields on the account and contact entity in reality are located in the Address entity.
Behind the scenes, Address entity includes a field called AddressNumber (not displayed on the address form). Address records linked to an account where AddressNumber = 1 will appear in the account address1 fields. Address records where AddressNumber =2 will appear in the account address2 fields. Addresses where Address Number = 3+ will appear in the default “more addresses” view.
Want to have all addresses appear in the list for account addresses? Clear the filter for the “All customer addresses” view.
Considerations for customizing address fields in Dynamics 365
Given the “split personality” of address (where it shows up on Account and Address for the first two addresses), special care must be taken when modifying addresses configuration in Dynamics 365. Let’s say you decide to replace the standard state, country, or postal code field with a lookup field to a custom entity. This can be a good idea, but since the custom field added to the account record is not also automatically added to the address entity, if you replace the account Address1 Country field with a custom country lookup field, the addresses created will not have a country value in the address table. And there is no supported way to modify the relationship mapping between account and address, so even if you add the same lookup field to address entity, your selection in the country lookup field will not automatically populate the custom country lookup field in the address entity. A common workaround is to have a workflow on account update the standard address text fields when a value is selected in the custom address lookup fields, ensuring that the value selected is recorded in the address entity.
The account entity and address entity also both have a field called addresstypecode (option set) for each address. This can be used to indicate the purpose of the address, such as mailing address, shipping address. However, these fields are not global option sets, so if you change the address type field options on the account, it is important to also update the address entity address type option set options to match. Otherwise, you may find your account billing address is stored in the address table as a shipping address.
If you have two main addresses, such as the billing address and the shipping address that need to be displayed on the account form, the recommendation is to add the address 2 fields on the form and designate the addresses for their defined purpose. You may also want to put each address into its own section and name the section for the type of address (“Shipping address” or “billing address”). This will ensure consistency in the way that addresses are used in Dynamics 365 accounts—address 1 will always be the shipping address and address 2 will always be the billing address. Consistency is very important for maximizing user adoption, and while there is an addresstypecode field for each address, keep in mind that users will create views and marketing lists of account data, including the address, and if you are not consistent in the use of the two addresses, these views could contain a mixture of address types.
Address validation options
Dynamics 365 does not include standard address validation; however, if you are licensed for and running Dynamics 365 for Field Service, company and contact addresses will be validated. There are also a number of good third party address validation options available for Dynamics 365, such as PCA Predict (https://www.pcapredict.com/dynamics/).
Accounts can be used to manage relationships with any company with which you do business. This can include customers, prospective customers, vendors, or any other type of company relationship. The account form contains many of the commonly used fields, but there are several account fields in Dynamics 365 that are not on the form by default. Review the existing fields not on the account form before creating new custom fields.
As you plan your deployment of account management, there are several questions to consider:
- Where will my data come from? If data is coming from an integration or migration, you will need to ensure that there are fields for each data component that you want to bring into Dynamics 365, verify that option sets and lookup fields contain data values to support the imported data, and that prerequisite dependencies are loaded first. If account data is coming from an integration, determine which system will be the “master for the account data. Typically this will be the ERP/financial system for primary account fields (like account number and account name). Lock these fields down in Dynamics 365 for integrated customer account records.
- What naming strategy will we follow? Remember that the account name field is really important, as it will appear in every lookup field that references account records. Typically the name should be the “friendly” name that most users refer to the company as. If needed, add a secondary name field for the official legal name of the company if different than the common friendly name.
- What is our parent account strategy? Dynamics 365 does a great job of handling hierarchical relationships between accounts, but you don’t necessarily have to create an account record for each location of your client companies. Create an account for each level of the company that you sell your products or services to, or for which there are distinct contacts with which you work. And remember that activities roll up to parent accounts, so if you need to monitor activity with multiple locations of a company, the parent activity roll up will make your life easier.
- How should we classify our accounts? We need to know who our customers are and how they are related to us. Dynamics 365 includes standard classification fields that can be used to identify how we are related to a company (Relationship Type) and other types of classification like Annual Revenue, SIC, Industry.
- How should we segment our accounts? You should segment your accounts so you can prioritize your sales efforts. There are multiple segmentation strategies, such as Strategic Account Management (SAM) and ABC Analysis. Good segmentation defines the client’s value to us, our value to the client, and client’s future potential. Once you determine your segmentation strategy, create custom fields for segmentation purposes and build account views by segment.
- How should we assign our accounts? Dynamics 365 is flexible enough to support multiple types of sales territory structures. Whatever structure you choose, it should be easy to administer, easy to restructure territories, and automated as much as possible.
- How should we manage company addresses? Remember that address data is actually stored in the “Address” entity. The account entity has the first two addresses, additional addresses are displayed in the related “Addresses” entity. If you make changes to addresses on accounts, such as adding custom fields or changing the address type option set, remember that these changes will not be reflected in the address entity.