Subscribe
Share
Share
Embed
Welcome to our podcast, where we dive into everything Go High Levelβfrom mastering the basics to tackling the most complex tasks. I use GHL daily in my business and rely on Google NotebookLM to stay ahead of the curve, keeping up with all the latest GHL features, tools, and innovations. This podcast is powered by AI, fueled by the research and insights I personally curate to bring you the most valuable and up-to-date content.
Copy this link for a free trial of Go High Level - https://www.gohighlevel.com/highlevel-bootcamp?fp_ref=amplifi-technologies12
Imagine pressing upload on a client's massive database. Right. You're waiting for that green success bar to load. And then suddenly you realize you're just accidentally wiped out the phone numbers of like 10,000 active leads. Oh, yeah, that is the absolute worst-case scenario. It is a total nightmare. It really is. So, today in the deep dive, we are ensuring that never happens to you and, uh, to make sure you have the perfect environment to practice everything we're about to cover. I want to let you know that you can get a free 30-day Go High Level trial right now. Which is an amazing deal, by the way. It is. That is actually double the standard trial length and the link to claim it is waiting for you right down in the show notes below, so definitely go grab that. Yeah, you really should because it's the perfect sandbox for this. Data migration is, I mean, arguably it's the most terrifying bottleneck for a digital marketing agency when they're onboarding a new account. Oh, 100%. So, our mission today is to dig into Go High Level's official support documents. And, uh, their recent update logs. We want to pull out the absolute most practical, actionable takeaways for mastering CSV imports. Right, because we want to help you move client data seamlessly and just completely bypass that dreaded error log loop. Exactly. And it all revolves around the CSV file, right? A CSV comma-separated values is essentially, well, it's the lowest common denominator of the digital world. Yeah, it's just raw text stripped of all the fancy formatting. Right, and that's exactly why it is the only language that every database universally understands. But to speak that language fluently, we really have to look at the biggest game changer High Level recently rolled out. Oh, you're talking about the dual object import? Yes, because we're moving away from what used to be a really stressful, like, two-step nightmare. You know, you imported contacts first, crossed your fingers, and then tried to import opportunities and map them together. Right. And now with the dual object import, it just fundamentally changes the workflow. You can upload both contacts and opportunities simultaneously using just one single CSV file. Which is huge. It is. If a contact and an opportunity sit on the exact same row in your spreadsheet, High Level's auto-mapping feature just automatically links them together in the CRM. Okay, but I've always wondered, like, how the system keeps that straight without duplicating people. Because if I have a client, let's say a real estate agent, and they have a buyer who is looking at three different properties. Yeah, so that's three different sales opportunities for the same person. Right. If those are on three separate rows in my CSV, how does the system know it's just one person? Ah, so it comes down to the deduplication logic. Think of High Level's deduplication logic like, um, like a bouncer at a highly exclusive club. Okay, I like this. Yeah. So the spreadsheet row is the ID you hand the bouncer. It doesn't really matter if John Smith shows up to the club wearing three different outfits over the course of the night, and those outfits represent those three different real estate opportunities. Got you. So what does the bouncer do? Well, the bouncer checks the email address or the phone number. That's the underlying ID. He recognizes it, and he lets all three outfits into the exact same VIP booth, rather than creating three separate John Smiths inside the club. Oh, I love that visualization. So the email or phone is the unchangeable ID. Exactly. But, you know, I'm looking at the options the system gives you when you actually run this import. You get three choices: create, update, or create and update. Right. Those are your import actions. I get create, I mean, that's just dumping a brand new list into the CRM. But if update only modifies existing records, what happens to the brand new leads mixed into that same spreadsheet? Do they just vanish into the ether? Yeah, so if you select update only, yes, any entirely new contacts on that spreadsheet are just completely ignored by the system. Wow, really? They just won't be imported at all. Not at all. The update function is purely a surgical tool. It's designed for when you say, export an existing list, run it through an external cleaning service, maybe you want to verify email deliverability and then bring it back in to refresh your existing database. Oh, so you do that without accidentally adding new junk data? Precisely. Ah, okay. So if I'm taking over a messy client account, and I'm bringing in a spreadsheet that has a mix of their old database plus like some new leads they bought last week, I have to select create and update. Yep. That's the one you want. That way the bouncer updates the VIPs who are already inside and opens the door for the new arrivals. Exactly. It is the perfect mechanism for auditing and organizing an existing client's messy pipeline without losing anything in transition. So if we have this incredible club with this smart bouncer, how do we make sure that people in line actually have the right ID? Let's talk about the raw materials. You mean the CSV structure itself? Yeah. And I'm looking at the file limits in the support docs, and I have to stop and push back on something here. Uh-oh. What is it? It says the file maximum is 30 megabytes. Wait, 30 megabytes? In 2026. I mean, that is practically nothing. Why is a top-tier CRM timing out on such a tiny file size? I know, I know. It sounds tiny when you think about like downloading a podcast or watching a video, but you have to think about the immense computational load of text data. Okay, fair enough. But 30 megs. Right. But a 30 megabyte CSV file isn't just a flat document. It contains potentially hundreds of thousands of individual data points. When you press upload, the CRM isn't just saving a file to a hard drive. Right. It has to process it. Exactly. It is actively reading every single cell, running that bouncer deduplication logic against millions of existing entries in the database in real time, checking for formatting errors, and routing data to pipelines. Oh, I see. So it's not a storage limit at all, it's a processing limit. Yes. It's trying to do a million complex math equations the second you hit enter. Exactly. If the file is too large, the server request simply times out before the math is finished. Ah, that makes a lot of sense. So the rule is strictly one sheet, maximum 30 megabytes and the very first row cannot be blank. It absolutely must be your header row. Because that header row is the map High Level uses to understand the columns, right? Oh, I got it. Okay. So, assuming my file is under 30 megs and has a header, what actually has to be in the cells? Like, what are the mandatory fields just to get through the front door? Well, for a contact, it's actually remarkably forgiving. You must have at least a first name, or an email address, or a phone number. Wait, just one of those? Just one of those three is enough to generate a baseline contact record. Wow. Okay, I can see why contact creation is forgiving, you just need one anchor point to build a profile around. Right. But opportunities, I mean, they represent actual revenue movement. I imagine the system requires a much stronger anchor there. Oh, it absolutely does. Opportunities require three specific pillars to stand up. Your row must contain a contact ID, so it knows who the deal belongs to. Makes sense. An opportunity name, and the pipeline ID or pipeline name, so it knows which board to put the deal on. Right. And if you are just updating an existing opportunity, you can actually get away with just the opportunity ID. Okay, let me throw a real-world scenario at you then. Because clients are, let's be honest, notorious for giving you incomplete data. Oh, always. What if they hand me a spreadsheet of 100 massive sales deals. They have the names, they have the pipeline, but they completely forgot to include what stage of the pipeline these leads are currently sitting in. Yeah, that happens a lot. Do all 100 of those deals just crash and burn on import? No, actually. And this is where High Level has built in a really smart fail-safe. If the stage ID or stage name is completely absent from your file, the system doesn't panic and reject the row. Oh, thank goodness. What does it do? It defaults to placing that opportunity in the very first stage of whatever pipeline you signed it to. Man, that's a life saver. Yeah. Basically just catches it at the top of the funnel so you can sort it out manually later, rather than just, you know, deleting the deal entirely. Right. And it executes a similar fail-safe for the opportunity value, like the dollar amount of the deal. Oh, really? Yeah. If a client leaves the value field completely blank, the system simply defaults to a zero dollar value, rather than throwing a fatal error. That's smart. It keeps the structural integrity of the import intact, even when human data entry is a little sloppy. So if the mandatory fields get you past the velvet rope, the formatting rules are making sure you don't trip on the stairs on the way in. That's a good way to put it. And looking through these docs, this is clearly where agency owners step on landmines. Let's disarm some of these, because a few of them seem entirely invisible until your import blows up. Let's start with phone numbers. Okay, let's do it. The docs insist on the E.164 format. For the listener, what does that actually mean? Right. So E.164 is simply the international telecom standard. It means a plus sign, the country code, and the phone number, with absolutely zero spaces or dashes. Okay. So for the US, it's plus one, followed by the 10 digits. But let's be real, a client is rarely going to hand over a spreadsheet formatted perfectly to international telecom standards. Are standard US formats going to break the system? Standard US formats are generally accepted. Oh, phew. Yeah. If the number has dashes between the digits or puts the area code in parentheses, the system's parser is usually smart enough to strip those out. That's good to hear. Where do people mess it up then? Where people inevitably step on a landmine is having letters in the phone number field, like someone literally typing out the word extension followed by a number. Oh, no. Or having erratic random spaces in the middle of the digits, that will instantly break the validation. Okay, so keep letters out of the phone column. Yeah. Got it. What about dates? Why are dates such a sticking point? Because dates aren't just text on a screen, they're the mechanical engines that power time-based automations. Right. If you have a workflow that triggers a contract renewal sequence exactly 30 days before a date in your database, that date needs to be mathematically perfect. It must follow a strict structural format. Like what? Like MMDDYYYY using slashes or dashes or YYYYMMDD, you have to pick one recognized format and stick to it rigidly throughout the entire column. If you mix formats, the automations will misfire. Yeah, that makes perfect sense. Now, here is one that really caught my eye. Multi-select fields. Oh, yes. If I have a column for tags, I want to tag someone as a VIP and a hot lead. The docs say I can separate them with commas, semicolons or periods. But they put a massive bold warning that slashes are strictly invalid. Yes. Strictly invalid. Why does a simple forward slash bring the whole thing crashing down? It comes down to how machines read text. In database programming languages, a slash often acts as an escape character, or it indicates a directory path like a website URL. Oh, like a web address. Right. So when you put a slash in a CSV cell, like typing VIP/lead, the system's JSON parser panics, it thinks you're suddenly trying to write a line of executable code or point to a file folder, rather than just writing a simple text tag. Wow. It rejects the cell to protect the database from running bad code. Okay, so no slashes in multi-select, ever. I love understanding the why behind it. It's not an arbitrary rule, it's a programming safety measure. Exactly. Speaking of arbitrary rules, though, I have to bring up countries and time zones. I had a feeling you would. The documentation has this massive table of accepted exact spellings. Like United States is accepted, but USA or US will trigger an error. I really struggle to see the logic here. A smart CRM should easily recognize that USA and United States are the exact same place. I completely understand the frustration there. I really do. But if we connect this to the bigger picture, the system is actually protecting you from yourself. Protecting me from myself. Yes. The underlying philosophy here is strict data validation upon entry to prevent massive silent segmentation errors later on. Walk me through that. How does USA cause a segmentation error? Think about it from the perspective of running a highly targeted campaign. Let's say six months down the line. Your agency decides to run a geographical email campaign specifically targeting leads in the United States, maybe for a regulatory update. Okay. You go into your smart list and you filter the database by country equals United States. If the CRM had loosely accepted USA, US, and America during that initial import without standardizing them, all of those leads would be completely invisible to your filter. You would accidentally exclude thousands of people from your campaign simply because the CRM didn't force you to standardize the terminology up front. Ah. So by forcing the pain of standardizing the spreadsheet before the import, they are guaranteeing that the client's marketing automations will actually fire correctly six months from now. Precisely. It is short-term pain for long-term reliability. A uniform United States tag ensures the database is water tight. That does make sense. And the exact same logic applies to time zones. You have to use the exact accepted database strings like American New York, capitalized exactly that way, so that when an automation says send this email at 9:00 AM local time, the system isn't guessing what EST means. Standardization makes sense for broad targeting, sure. But clients rarely hand over standard data. They hand over messy, nuanced lives. And once you master the standard formatting, you inevitably hit these complex edge cases that if handled incorrectly, can cause a massive client relations nightmare. Absolutely. One of the most common edge cases is dealing with leads who have multiple emails or multiple phone numbers. Right. Almost everyone has a work email and a personal email. If I put both of those in the same email cell on my CSV, does the parser panic again? It does. You cannot put them in the same cell. You have to structurally separate them by creating new columns in your CSV. Okay. How does that look? You create a column called additional emails, and another called additional phone numbers. Inside those specific columns, you can put multiple secondary values separated by commas. High Level will read that specific header, import them properly, and save them as secondary communication fields on the single contact record. That's clean. What about notes? Because some clients have kept a diary of every interaction with a lead for the last five years. Yeah, there is a hard structural limit here. When you are importing notes via a CSV file, you are restricted to exactly one note per contact record, and that single note is strictly capped at 5,000 characters. So if a client has a massive multi-page history that exceeds that character limit, the import will likely just truncate it or fail entirely. Yes. You have to summarize it beforehand. Yes, or find an alternative way to migrate historical logs, because the CSV import is not designed to be a limitless filing cabinet for text. Good to keep in mind. But, uh, I want to pivot to the edge case that I think is the most genuinely dangerous thing we're covering today. The DND trap. Yes. I actually had a colleague who ran into this exact scenario. He imported a list of about 5,000 real estate leads for a client. The client wanted to pause SMS marketing for the weekend, so my colleague thought he'd be clever. Oh, no. He added a column labeled DND, do not disturb, and put a yes next to all 5,000 contacts. He thought he was just pausing texts. But he didn't. He accidentally blacklisted the entire list. The client couldn't email them, call them, or text them. It was a complete blackout and a massive relations nightmare. The DND trap. It is terrifying, and it is a very common mistake. If you use the standard DND column in your CSV and map it directly into High Level, the system treats it as a nuclear option. A nuclear option. Wow. It automatically applies a blanket block to all communication channels simultaneously. SMS, email, phone calls, voicemail drops, everything is shut down. So, how do we disarm this? What is the actionable takeaway to apply DND to just one specific channel without triggering a total blackout? To apply channel-specific DND like SMS only, you must skip the CSV DND column entirely. Do not map it to the system. Okay. Instead, you create a column in your spreadsheet for tags. You tag those specific users with a unique identifier, something like DND SMS. I see where this is going. You're using the tag as a trigger. Exactly. You will have previously set up a workflow inside High Level that dictates a rule. Like, when a contact receives the tag DND SMS, restrict their SMS channel only, but leave the email channel open. When you import the CSV, High Level reads the tag, fires the workflow, and applies the nuanced logic perfectly. You use the CSV purely to deliver raw data, and you let the CRM's workflows handle the complex business logic. That is incredibly smart. Keep the CSV simple, let the CRM do the heavy lifting. So we've navigated the formatting landmines, we've dodged the DND trap, and we have finally built the perfect CSV file. Which is an achievement in itself. Truly. Now, we hit the final phase, the actual upload, mapping and monitoring the execution. Right. So when you upload the file, you enter the mapping phase, where High Level tries to match your spreadsheet headers to its internal database fields. And there is one tiny checkbox on this screen that is arguably the most important button in the entire process. Oh, really? It's labeled don't update empty values. Okay, I'm looking at this checkbox and trying to trace the logic. If I'm updating an existing contact database, and my spreadsheet has a blank cell for a client's phone number. Does the CRM view that blank cell as data? Yes. Oh, wow. If you do not check that box, the system looks at your blank cell, assumes your intention is to delete the phone number, and it will overwrite the existing CRM data with nothing. You will wipe out valuable existing information. That is terrifying. Checking don't update empty values ensures that if the system encounters a blank cell in your CSV, it simply skips over that field and leaves whatever is currently sitting in the CRM perfectly intact. Note to everyone listening: check that box. It is a literal data saver. Now, what if the client gave you a spreadsheet with 10 columns of absolute junk data like internal employee ID numbers that you just don't care about? Do you have to painstakingly map them to dummy fields? No, thankfully not. You can choose to leave unrecognized columns entirely unmapped. The system will flag them and prompt you, and you just check a box confirming you want to proceed without importing them. That's super convenient. It's a great way to filter out the noise on the fly without having to manually delete columns in Excel first. And right after the import finishes, before you even leave that success screen, you can actually do some automated organizing. Right. Yes. Immediately upon import, you are given advanced actions. You can add all those newly imported contacts directly into a smart list, drop them straight into a workflow, or apply a universal tag to the entire batch, which saves you from having to hunt them down in the database later. But let's be honest, we don't always get the green success bar. What if things go wrong? Where do we monitor the damage? Monitoring happens in the bulk actions page. Both your contact and opportunity imports will populate there. You click show stats and this opens your error log. And it's crucial to understand how High Level mechanically differentiates between errors and warnings. What is the mechanical difference? An error indicates a catastrophic failure in a mandatory field, like a missing email and phone number. The row completely failed to import. Got it. And a warning? A warning indicates a minor failure in an optional field. Maybe one of your multi-select tags had a slash in it, causing the parser to panic. In the case of a warning, the row still successfully imported and the contact was created, but that one specific broken field was skipped and left blank. So it's not a total loss. Exactly. You can actually download the error log, fix just the broken rows, and reimport them without duplicating your work. We have gone incredibly deep on the mechanical rules, the landmines, and the workarounds of CSV imports today. But I want to pull back for a second and look at the bigger picture. Because this technology is moving incredibly fast. It really is. As platforms like Go High Level continue to introduce features like the dual object import and auto-mapping, we are moving rapidly toward a future where data entry requires less and less technical friction. And before we sign off, I want to leave you with a thought on exactly that. We've spent this entire deep dive mastering the strict rigid rules of CSV mapping. No slashes, exact time zones, mandatory IDs. But with large language models and AI becoming deeply intrinsically integrated into CRMs, how far are we really from a day where the CSV becomes obsolete? That's a huge question. Imagine a future, maybe just a few years away, where you don't even need a spreadsheet. You just dump a messy PDF, a text document or even a voice transcript into High Level and the AI perfectly categorizes, tags, and structures the database for you without a single mapping error. Wow. The era of the CSV and all the headaches that come with it, might be coming to a close sooner than we think. It's a fascinating prospect. It shifts the agency's role entirely away from technical data management, leaving them to function purely as high-level creative and strategic advisers. The tools are doing the heavy lifting, which means your clients are going to demand more from your actual marketing strategy. And on that note, we are going to wrap up today's deep dive. This was a good one. It really was. I want to remind you one final time, if you want to explore these import features, test out the dual object upload and see just how seamless your client onboarding can be, the link for the free 30-day Go High Level trial is waiting for you in the show notes. Go click it. Remember, that is double the standard trial length, giving you a full risk-free month to build your workflows and test your data. We highly encourage you to click that link and put these CSV import strategies to the test right away. Until next time, keep those spreadsheets clean, and we'll see you on the next deep dive.