A lot of us have either inherited or created a franken-tech stack. Tools are connected to the CRM and marketing automation platform. Things run slowly, end users complain about how hard it is to do their job, and some people suspect that the data is suss (as the kids say).
These wondrously frustrating outcomes don’t happen because the people standing up your technology stack were bad at it – although inexperience and the company’s refusal to invest in experienced resources can and do exacerbate things. These messes are never intentional, and even the most experienced implementation experts can’t predict future business changes that will make certain features obsolete.
Companies change constantly, and it’s normal (unfortunately) for an ever-growing list of things to fix to hit the back burner when a new initiative or, if we’re honest, an executive gets a random bee in their bonnet. Here are the most common issues we see in the market and how to fix them, plus a few strategies for cutting back on technical debt sprinkled throughout.
CRMs and marketing automation systems (MAS) all have API limits. Since these tools are at the heart of every go-to-market technology stack, it’s mission-critical to 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 - although they do move things around, so we recommend checking out their help documentation.
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:
Click on the system name to view the limits for the following systems:
For any other system, use your browser to search your system name + “API limits.”
To avoid locking out users at the end of the quarter (I’ve seen it happen, and it was NOT GOOD) before you make changes in a marketing automation system, CRM, or any system integrated with your CRM, ask yourself:
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 MAS administrator to double-check your math. When in doubt, wait until after business hours or until the weekend to run the process.
Trying to cap a threshold for the number of contacts in your MAS in smaller organizations isn't uncommon. 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.
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. For example, many, many duplicates!
The most detrimental example is losing visibility into which contacts have opted out of all communication. This can lead to a lawsuit.
Some MAS 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). Consider contracting with a consulting firm if you see a lot of duplicates in one system but not the other or suspect you may have lost visibility into opt-in and opt-out information.
Use standard objects and fields wherever possible. Updating non-standard fields in some systems will create a greater burden on your API calls. MASs are very restrictive in the number of objects they allow because they’re protective of how much processing power is dedicated to each instance.
Carefully evaluate your MAS to CRM integration and be ruthless about what is necessary to sync and what can live in a single system. Summary fields may also be a great workaround for creating a custom object.
For example, you may need an account indicator to show what kind of product families a company has active instead of creating a custom product object in your MAS. If the setup is correct (which should be tested), you can more easily segment your customer lists and send them the correct messaging without bloating your MAS.
When you purchase a new tool, you can usually choose between using standard fields or creating custom fields. Whenever possible, use standard fields! Some MASs don’t allow you to delete fields, and field proliferation can be expensive, confusing, and messy.
One of the more common reasons for infighting between marketing in sales is data. Who inputs it, what gets overwritten, and who doesn’t input it. When it comes to encouraging people who just want to hit quota to spend time doing data entry, eliminating any kind of system override that undoes their latest update will save you the heartache of trying to convince jaded salespeople to try something that has failed them in the past.
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. Marketo is pretty fantastic because it allows you to specify an order of operations, which is rare! In other instances, you may need to introduce a workflow tool to ensure the right things are happening in a proper sequence.
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).
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.
I’ve personally experienced this with lifecycle processing or funnel stage updates. We had three systems fighting over the same field, and it created conflict between marketing and sales. Marketing wanted to know why leads weren’t being followed up on, and sales wondered why marketing wasn’t generating leads. The reality was that leads were being sent from the MAS, routed by the CRM, then immediately put into an inactive status by a data warehouse.
Oops.
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 CRM error logs and track down the cause for anything repetitive.
Some systems require an active user to be associated with an integrated system 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 deactivating a user will negatively impact an integration. 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.
Imagine spending five minutes trying to create a record only to have it fail several times because fields aren’t populated – and half of those fields aren’t used anymore by the executives who asked for them.
I worked at an organization with over 20 validation rules on the opportunity object. I had to record salespeople trying and failing to create records and then make a couple of executives try to create an opportunity in a meeting before I could convince them the current setup was untenable.
Remember that data entry is only a small part of your go-to-market team’s jobs. I recommend a quarterly audit to make sure your validation rules aren’t getting out of hand.
Validation rules are also a very common point of failure for integrations. A workaround is writing an exception in every validation rule to exclude the role used for integration users.
Deduplication and matching rules can prevent the proliferation of duplicates, but they can also implode your integrations. It’s a great feature and usually much needed, but administrators should proceed with caution and re-evaluate these rules when new systems are integrated.
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.
Standardization is never a bad thing unless it blows up an integration.
When you decide to use any picklist (state, 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) update(s). Proceed with caution when mandating standardized values.
A full sandbox is an excellent platform to test configuration changes, but you should always push change sets 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 on how to QA changes and communicate what’s happening to your end users.
It’s not uncommon to be handed a data hygiene project or to be told that a list of system fields should be pulled only for those tasks to sit on the backlog for months. It’s difficult to prioritize a page layout update when projects like a CPQ implementation or integration with your financial tool looming over your head.
It’s also not uncommon to hear the words “it should only take five minutes” come out of the requestor’s mouth when you push back on doing the thing immediately.
Take a deep breath. They don’t understand that dropping everything to do a “five-minute ask” that will undoubtedly be connected to a bunch of other stuff that will be impacted and subsequently need an update is like asking a deep water diver to give into their instinct to breathe at the bottom of the ocean. Stay cool.
Using a task management tool like Asana or Jira to log requests like this will help your management team visualize the number of tasks done each week and how impossible it is to stay on top of every request. Taking the time to estimate the effort needed for these backlog tickets can help you create an argument for augmenting your team with a consultant to knock out some of the simpler asks. You can also check out our article on building a business case to get some ideas on leveraging that same data set to argue for additional headcount in a way your CFO will understand.
Did we miss something? Let us know by hitting up Camela Thompson in the RevOps Co-Op.
Looking for more great content? Check out our blog and join the community.