12 Common CRM and MAP Disasters
It was the end of the half, and I was filling in for the deal desk. The phones were busy, but something changed. My cell phone was blowing up.
Our marketing operations person decided that today was the day to update a bunch of records in Marketo and blew past our API limit.
On quarter end with only hours left to process bookings.
With a $250K deficit from the company plan.
Our CRM admin had our Salesforce representative on speed dial, and we were able to temporarily up our API limit.
It was a bad day for the marketing operations rep and almost a bad day for the sales. They were relying on the deals coming in that day to meet the global number and several account executives just short of quota.
Locking people out of a system they need to do their job is never good, but getting between a salesperson and their income is one of the worst places to be. So be on the lookout for these common catastrophes (and avoid the companywide sh*t list).
01 API Limit Exceeded
CRMs and marketing automation platforms (MAP) have API limits. These gate the number of calls to or from an external system, and systems can process these calls either as one API call for a batch or one API call per record.
It is critical that you know your daily limit, monthly limit, and how your systems process the calls (batch or by record).
In Salesforce, you can review your API limits by going to the System Overview page in Setup.
Salesforce used to show the monthly API limit, and they should today because it’s still a thing! Your monthly rate is your daily rate times 30. So if you’re not exceeding your daily limit regularly, you should be fine during the month.
To reduce your chances of exceeding your API limit in Salesforce:
- Configure Messages on the Setup -> System Overview page to show an alert on the Home Page for API Messages
- Review your Salesforce Error Log regularly and fix recurring errors
- Limit the number of fields you sync between systems (and mark any unused field as “Do Not Sync” in the system you’re integrating)
- Don’t use Salesforce as your mass emailing tool
- Review all integrated systems and their update frequency (check Setup -> Login History for a complete list)
- Use bulk or batch updates whenever possible
- Optimize your custom code to minimize API calls
- Wait to integrate new systems or turn new processes on at the beginning of a selling period and preferably in the evening or during the weekend
Click on the system name to view the limits for the following systems:
For any other system, Google your system name + API limits.
Word of warning: If you manage a marketing automation platform, CRM, or any system integrated with your CRM, ask yourself:
- Will this update impact records in our CRM or MAP?
- Is this change a batch API call, or will each record be an API call?
- Is it month, quarter, or year end?
- If this will impact several records, can I wait until the evening or weekend to process the change/turn on the process?
If you answer yes to one or more of these questions, research the impact it could make on your system and talk to your CRM or MAP administrator to double-check your math. When in doubt, wait until after business hours or until the weekend to run the process.
02 “You Have Exceeded Your Contact Limit”
It isn’t uncommon to try to threshold the number of contacts in your MAP in smaller organizations. It’s something I never recommend (see issue #3 on this list), but I understand the need to cut costs wherever possible. Fortunately, some tools have changed their pricing models to be based on usage versus sheer record volume.
If your organization is trying to save money by adding a threshold for person counts, check with your vendor to see if any other pricing models are available to your organization. Otherwise, you’ll be checking your contact record count weekly (at least). Hubspot offers a Marketing vs. Non-Marketing content designation that allows organizations to keep their MAP synced with Salesforce and keep their costs down.
Nice job, Hubspot.
03 Disparate CRM & MAP data = CHAOS
Whenever possible, keep your people records synced between your systems—not taking advantage of complete table integration results in outdated information in one or both systems.
The most detrimental example is losing visibility into which contacts have opted out of all communication. This can lead to a lawsuit.
Some MAP and CRM integrations are better than others. Marketo has the best integration I’ve seen. Others will often require a deduplication tool or close monitoring of the order of operations (see item 5 on our list).
04 Too Much Customization
Use standard objects and fields wherever possible. Updating non-standard fields in some systems will create a greater burden on your API calls. MAPs are very restrictive in the number of objects they allow, and there is a reason for this (processing load). Try to keep your information centralized in a single location and limit external updates wherever possible.
When you purchase a new tool, usually you can either use standard fields or create custom fields. Whenever possible, use standard fields! Some MAPs don’t allow you to delete fields, and field proliferation can be expensive, confusing, and messy.
05 (Dis)Order of Operations
Think through which system should win when it comes to updates, and then research the timing. For example, if you have sales users on the phone with people and update the email addresses or phone numbers, you never want to overwrite that information with enrichment data that may be stale.
If possible, research how a tool that will be integrated with your CRM handles merging. Merging and deleting tend to cause the most chaos between systems. It’s also very easy to create conflicting orders in two or more systems that ping pong off each other (which is covered in our next section).
06 The Loop of Doom
Suppose you have processes in multiple systems updating the same field or an interconnected series of fields. In that case, you may send conflicting messages and cause the systems to reprocess the field over and over.
Another cause of loop errors or errors from too many update requests on a single record can be apex custom code, flows, or improperly configured Zapier, LeanData, or Workato processes. Be sure to monitor your error logs and track down the cause for anything repetitive.
07 Inactive Owner
Some systems require an active user be associated in an integrated system in order to process a record. If a user is deactivated and the system tries to run an update, it will spew back errors, try again, and then spew back more errors (eating up API calls in the process).
Coordinate with other system administrators to understand whether an integration will be negatively impacted by deactivating a user.
Many systems allow freezing a user rather than deactivating them, meaning they can’t log into the system but are still considered “active” by any processes. Freezing users rather than deactivating them can give you time to change record ownership and avoid negatively impacting any systems.
08 Over Validation
Validation rules can cause integrations to fail. I recommend a quarterly audit to make sure your validation rules aren’t getting out of hand. A workaround is writing an exception in every validation rule to exclude the role used for integration users.
09 Global Deduplication & Matching Rules
Deduplication and matching rules can prevent the proliferation of duplicates, but they can also implode your integrations. I recommend running a process post-integration to flag duplicates created by integration users, researching how systems handle merges, and writing an exception excluding integration user roles from your duplicate and matching rule sets.
10 State and Country Picklist Blockage
Standardization is never a bad thing unless it blows up an integration.
When you decide to use any picklist (state and country or otherwise), coordinate with all system admins to ensure they know about the change and have time to update the processes in their system.
Picklists aren’t something you can work around and can block a record (or 8,000-record) updates.
11 Too Little Testing, Too Many Errors
A full sandbox is an excellent platform to test configuration changes, but you should always push changesets during off-hours and test your changes in production. You should also always make changes in your sandbox before touching anything in production.
No exceptions.
(You heard me.)
See our change management article for more great recommendations.
12 Oops. Now you have 8 billion fields forever.
Some platforms don’t allow you to delete fields (I’m giving Marketo the stink eye right now). Unfortunately, this means that those tools your team wants to test out that create a ton of custom fields are FOREVER.
Use standard fields whenever possible (we realize we’re repeating ourselves, and it’s on purpose) or risk having to replace your org in the future.
Did we miss something? Let us know by hitting up Camela Thompson or Erin O’Neill in the RevOps Co-Op.
.png){kind=icon}
