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, uh, losing a $50,000 client renewal, right? And it happens just because a single critical follow-up task was logged under a CEO's personal contact record instead of the actual company's Q3 sales pipeline. Oh, yeah. That happens way more than people admit. Right. Like the sales team thought the account manager had it. The account manager thought operations was handling it. I mean, in the digital marketing agency world, siloed data isn't just, you know, a minor annoyance. It is a massive quiet leak in your profit margins. It really is. I mean, it's the silent killer of agency scale. Yeah. Because when your operational data lives in these fragmented little silos, the actual work, the task itself gets completely disconnected from the broader context of a client's ecosystem. Yeah. You end up, you know, managing the chaos instead of actually managing the client. Exactly. And if you are listening to this right now, you are likely an agency owner, which means you probably spend a huge chunk of your week trying to engineer that exact chaos out of your systems. So, welcome to today's deep dive. Glad to be here. We have a seriously foundational workflow upgrade to unpack today that tackles this exact problem. We do. But, hey, before we get into the mechanics of it, I have something really special for you. Right now, you can get a free 30-day GoHighLevel trial that is double the standard trial length, by the way. And the link for that is waiting for you in the show notes below. That's a huge deal. It really is. I highly recommend grabbing that, you know, loading up some sandbox data and actually playing around with the architecture we're about to discuss. Yeah, testing it out firsthand is crucial because what we're looking at today isn't just like a new button or a cosmetic UI update. Right. It's a fundamental shift in the underlying relational database architecture of how HighLevel handles day-to-day operations. So, our mission for this deep dive is to explore the real-world business implications of HighLevel's new multi-object task associations. I know it sounds incredibly technical on the surface. It does sound a bit dry. Yeah, but this is really about fundamentally changing how your sales, success, and fulfillment teams communicate with each other. Exactly. And to understand the magnitude of this update, we really have to look at the structural limitations of, well, how things used to be built. Lay it out for us. So, previously, tasks in HighLevel operated on a strictly one-to-one data model. Specifically, they were contacts only. Right. If your team had a to-do item, it had to be tied to a specific individual person's contact record. There was just no flexibility there. Which honestly, simply doesn't reflect the reality of how a modern agency operates. Not at all. Like a deliverable is almost never just about a single person. If you're launching a massive rebrand campaign, that task involves the primary contact, sure, but it also involves the company entity itself. Exactly. It involves a specific sales opportunity or a pipeline stage. It might even involve a completely custom object you've built out just to track website deployment phases. So, tying it to just John Smith makes no sense. Precisely. That previous limitation basically forced different departments to work with operational blinders on. But HighLevel has now completely removed that contacts-only constraint. You do. Yeah. You can now connect one single task to multiple objects at the exact same time: contacts, opportunities, companies, and custom objects. Wow. Yeah, it shifts task management from a rigid one-to-one model to a really dynamic one-to-many model. Okay, let's ground this in a scenario because I know every agency owner listening has dealt with the friction of the old model. In the old system, a task was essentially like a heavy physical filing cabinet, right? That's a good way to put it. It could only sit in one single room. Yeah. If the sales team needed to see a deliverable status, they literally had to walk over to the operations team's room to look in their cabinet. And to avoid doing that, agencies started creating what we call clone tasks. Ugh, yes. The clone task. It is the ultimate symptom of bad data architecture. Right. You had account managers copy-pasting the exact same to-do item, like one for the contact record, one for a note in the opportunity pipeline. Maybe dropping another manual ping in Slack. Yes. Just like crossing their fingers and hoping everyone saw it. And those clone tasks are just a massive drain on productivity. But honestly, more importantly, they are a nightmare for data hygiene. How so? Well, think about the risk. When you have three duplicated tasks representing one real-world action item, what happens when the status changes? Ah, right. Right. Like if an engineer finishes the work and checks off the task in their specific custom object view, the clone task sitting over in the sales pipeline still shows as incomplete. Oh, that's the worst. Now you have conflicting sources of truth. Exactly. So the sales rep thinks the project is delayed and sends an unnecessary, you know, apology email to the client, while the dev team has already completely moved on. It creates completely unforced errors. Exactly. What this new one-to-many relational model does is eliminate the need for clone tasks entirely. You have one single action item. One record in the database. Just one. Just one. But you link it to all the relevant objects. It creates true end-to-end visibility. The sales team, the success team, and operations can all follow the exact same real-time source of truth. Regardless of which module of the CRM they happen to be working in. Precisely. So, if we go back to the filing cabinet metaphor, this new update is like putting a window into every room of your agency that looks at the exact same centrally located whiteboard. Oh, I like that. Right. You aren't duplicating the whiteboard. You're just adding more windows, so everyone can see it from where they already sit. That is a perfect way to visualize the architecture. Yeah. You are sharing access to a single point of data, rather than duplicating the data itself. Okay, let's unpack this a bit, though. Because if I am suddenly attaching a single task to three or four different objects at once, my immediate fear is data overload. Sure. Like, if the task is everywhere at once, does that mean it clutters up every single board? If my team logs in on Monday morning, how are they not just drowning in a sea of cross-linked notifications and irrelevant noise? Yeah, and that is the exact trap that a lot of enterprise CRM platforms fall into when they introduce cross-object linking. You solve the visibility problem, but you accidentally create an overwhelming noise problem. Right, nobody wants more noise. Exactly. But HighLevel engineered this system to intentionally prevent that clutter, and they did it without requiring your team to do a bunch of manual data entry. They built a system of what they call smart defaults. Okay, walk us through how those mechanics actually play out in the day-to-day workflow? Because, I mean, if my team has to manually link a dozen things every time they create a simple to-do, they just won't adopt the feature. Oh, absolutely. The friction of data entry will kill the utility every time. Yeah. But the system is designed around contextual awareness. The platform looks at exactly where you are located within the CRM when you hit the add task button and it pre-links records based on that specific context. Okay, give me an example. Let's look at the baseline scenario, the Global Tasks page. If you create a task from there, it starts with zero associations. It's a completely blank slate. You have to intentionally pick the records you want to attach. Which is super logical. I mean, if an account manager is just brain-dumping a general internal to-do list for their Friday afternoon, we do not want those administrative tasks automatically sticking to random client files. Right, that would be a mess. But the real power kicks in when you are working inside specific records. Let's say you're working inside a contact record. Okay. You're looking at a client, let's call her Sarah, and you click Add Task. The smart default recognizes your location and automatically pre-links Sarah the contact, plus her primary company, if she has one assigned in the system. Oh, wow. So the system assumes that if I'm interacting with Sarah, the action item probably involves her broader business entity? Exactly. Two connections established, zero extra clicks required from the employee. That's great. It really reduces the cognitive load on your staff. But the most powerful smart default, particularly for the way digital agencies operate, happens in the opportunity view. The sales pipeline. Yes. If an account executive creates a task directly from an opportunity card in the pipeline, the system automatically pre-links the opportunity itself, the primary contact associated with that deal, and that contact's primary company. Wait, all three? All three layers of the client ecosystem are captured and linked instantly. Okay, so the actionable takeaway here for agency owners is standardizing your operating procedures. Like, you need to train your teams to initiate their tasks directly from the opportunity pipeline view. Yes, absolutely. If they do that, the platform automatically ties the internal work to the revenue-generating deal, the decision maker, and the business entity. It creates a perfectly documented paper trail with a single click. Okay, but let me play Devil's Advocate here for a second. Go for it. I see how the automation saves time, but what happens when the system guesses my intention incorrectly? Like, what if I am working inside an opportunity, but I specifically do not want the primary contact tied to this internal agency task? That's a very real scenario. Right. Let's say it is a highly sensitive back-end task about uh, reassigning a budget or discussing profit margins on a retainer. I don't want that internal financial task appearing anywhere near the client's outward-facing contact feed. Does the smart default force my hand and link them anyway? No, not at all. It's a critical distinction to make between a hard-coded rule and a default suggestion. You are never locked in. Oh, good. Yeah, the smart defaults are designed to eliminate repetitive data entry for the 90% of tasks that follow a standard pattern. However, you retain absolute granular control over the relational links at the point of creation. How does that look in the UI? When the task creation window opens, there is a dedicated associate-to dropdown section. You simply click the little X next to the contact's name, and that relational link is severed before the task is even saved. Oh, okay, that makes total sense. So the task remains linked to the opportunity and the company, but the individual contact is completely removed from the equation. Precisely. You get the speed of the automation without sacrificing the precision of manual control. You're maintaining the internal firewall when you need to, but riding the efficiency of the defaults when you don't. Exactly. All right, so the creation side is smooth, the architecture makes sense, but let's shift to the retrieval side of the equation. Knowing how easily these tasks can be created and cross-linked is great in theory, but how do agency owners actually use this to track work? Like if I am managing 50 active client retainers and my team is generating hundreds of these multi-object tasks a week, how do I actually parse that data? This is where we look at how the visibility and filtering capabilities have been completely overhauled to support this relational architecture. Right. First, from a pure visibility standpoint, every single contact, opportunity, company, and custom object record now features a dedicated associated-objects section within its task panel. Meaning, if I open up an opportunity for like a Q4 ad spend increase, I don't just see a flat list of task names. Right. I see the entire relational web. I see exactly what other parts of the CRM that specific task is touching. Yes, and the user experience design here is quite elegant, honestly. When you are viewing a list of tasks, any task with multiple associations displays a small chain link icon. And rather than forcing you to click through multiple screens to understand the context, hovering your cursor over that chain link instantly drops down a preview of all the linked records. Wow, I really appreciate that level of UX detail. I mean, every extra click you require an employee to make across hundreds of tasks a week, it really adds up to hours of lost productivity. Absolutely. So, if an operations manager can just hover, see that a task is tied to the Summer promo opportunity and Acme Corp the company, they immediately have the context they need to prioritize it. And if they do need to investigate further, clicking any of those record names in the hover state automatically opens that specific record in a new browser tab. Nice. Yeah, it ensures they never lose their place on their master task list while they're investigating a specific client file. That is a massive operational time-saver. But what about building specific targeted lists? Like, if it is Monday morning and I'm running a production meeting with my web development team, I don't want to see every task in the agency. Of course not. I only want to see what is relevant to them and maybe only for a specific category of work. Because these associations are deeply integrated into the platform's core data structure, the filter power is immense. You aren't just searching for text strings, you are querying the relational database. Oh, that's powerful. Very. You can use the filter icon on the main tasks page to slice and dice the agency's workload by combining these new object associations with traditional parameters. So I can cross-reference things. Exactly. You can literally query the system to say, show me all tasks that are currently marked overdue that are assigned to my lead developer David and that are explicitly associated with the website audit custom object. And it just pulls it up. The system parses that complex relational query and delivers a laser-focused list in seconds. That is project management gold right there. I mean, that level of granular filtering is exactly how you prevent high-value deliverables from slipping through the cracks during a really busy week. For sure. But wait, bringing up the lead developer introduces an interesting variable. Yeah, if a task is linked to a custom object and an opportunity and a company, how does the system handle user permissions? Ah, the security question. Right. Let's say I have a junior graphic designer on my team. For security reasons, they only have permission to access a specific custom object. Let's say it's just the logo design file object. Okay. But the account manager creates a multi-object task and links it to that logo design object, but also links it to a highly confidential company record for a massive enterprise client. I see where you're going with this. Yeah. The junior designer specifically does not have access to that enterprise company file. Does linking the task to a restricted object suddenly make the task disappear from the designer's queue? We look at the broader implications for agency data security. This is arguably the most complex architectural hurdle HighLevel had to clear. I bet. Yeah, they implemented a very specific operational-first permissions rule. Here it is. A user can see and interact with a task as long as they have access to any one of the associated records. Wait, let me make sure I am fully grasping the operational impact of that. Because the junior graphic designer has access to the logo design file custom object and the task is anchored to that object. Right. They can see the task on their to-do list, even though it is simultaneously anchored to a restricted company record. Correct. The system prioritizes operational flow over restrictive blanket hiding. They can see the task, they can read the description, they know the due date, and they can mark their portion of the work complete. But what about the confidential info? The security firewall remains completely intact. If they attempt to click the link to view the confidential company record, the system will just block them. Oh, that is an incredibly smart way to handle it. It ensures the designer has the exact context they need to execute their specific job function, without requiring an agency owner to compromise their master CRM data. Exactly. You don't have to grant full administrative access to a junior employee just so they can do their job. They can just put their head down and work while leadership rests easy, knowing the client financials are shielded. It's the perfect balance of visibility and security. But, you know, to maintain platform stability and keep the database queries running fast, there are some necessary structural boundaries. Core guardrails. Yeah. You cannot endlessly link a single task to hundreds of different records across the CRM. Okay, so what are the actual guardrails we are looking at? The platform-wide limit is set to 10 records per object type on a single task. Let's break down the math on that. 10 per object type. So, on one single action item, I could link up to 10 distinct contacts. Right. Plus, up to 10 different opportunities, plus 10 companies, and 10 custom objects. So, theoretically, one task could be tied to 40 different entities simultaneously. That is the hard technical limit, yes. I'm going to push back on the reality of that limit for a moment. Right, let's hear it. 10 per category sounds generous on paper, but I guarantee you, if an agency is running a massive multi-city franchise campaign, some project manager out there is going to hit that limit. They will have one huge marketing push that applies to 15 different regional sales opportunities, and they are going to complain that the system is artificially restricting their workflow. That is a totally valid concern for enterprise-scale campaigns. The technical documentation notes that this limit is strictly enforced platform-wide to ensure data retrieval remains instantaneous. If they didn't cap it, the UI would just buckle under the weight of endless relational loops. You know what? Actually, if I can offer a purely operational insight on that. Yeah. If an agency project manager is trying to attach a single solitary task to 15 different sales opportunities, they are fundamentally misunderstanding what a task is. Oh, yes. That is not a to-do item. That is a massive project. If you find yourself hitting the limit of 10 opportunities for one checklist item, that is the system's architecture practically screaming at you that your scope of work is entirely too broad. That's a really good point. Right. Agency owners should actually use that 10-item limit as a built-in leadership boundary. Use it to force your managers to split up their team's workloads into more manageable phases. Break that massive franchise initiative into three distinct regional tasks. I love that. Your fulfillment team will execute faster because it is significantly less overwhelming to look at on a Monday morning. Framing a technical database limit as a forcing function for better delegation is an excellent way to look at it. It enforces better operational hygiene. Absolutely. But speaking of operational hygiene, we do need to address the transition period. A major concern for any agency owner undergoing a CRM architecture update is data preservation. Oh, yeah. What happens to the historical data, the legacy tasks? Agencies probably have thousands of tasks created over the last year under the old contacts-only architecture. Do those just break? No, no. The system treats historical data with strict preservation rules. Tasks created prior to this release remain completely untouched. Okay, good. They remain linked exactly as they were to their original contact only. They will not break, and the system won't try to use AI to auto-update them or anything weird like that. Phew. However, HighLevel built-in backwards compatibility. You can open any legacy task, access the new associated-object section, and manually update it to the new multi-object model if you need to bring an old project up to speed. That is very clean. You aren't forced to migrate, but the option is there. Now, what about recurring tasks? Because recurring tasks are the lifeblood of agency retainers. Absolutely. Monthly SEO audits, weekly client reporting, quarterly strategy calls. If an account manager spends the time to meticulously link a recurring monthly task to an opportunity, a company, and a custom object, do they have to rebuild those complex relational links every single month when the new task generates? No, they don't. Oh, thank goodness. Oh, okay. Because that would be a deal-breaker. HighLevel anticipated that exact friction point. The recurring task engine has been updated to seamlessly inherit all associations from the original parent task. So when the new instance of the task generates next month, it perfectly mirrors the complex web of associations you established on day one. It is a true set-it-and-forget-it architecture. That is exactly the kind of operational leverage agency owners are looking for. Looking ahead, though, everything we have discussed today revolves around manual inputs in the user interface. Yes, it does. Relying on smart defaults, hovering over UX icons, clicking drop-downs. But the most sophisticated agencies run on complex GoHighLevel workflows. Can we automate these multi-object associations yet? That's the million-dollar question. Right. Like if a new enterprise lead drops in via a custom webhook, can a workflow automatically generate a task and instantly link it across three different objects without human intervention? As of this specific release, no. Ah, okay. The multi-object associations are currently managed purely within the UI. You cannot execute the multi-object linking via automated workflows just yet. That's a bummer. However, the product documentation is incredibly explicit about this. Adding these relational actions to the workflow builder is officially on the near-term product roadmap. Okay, just knowing the automation calorie is on the horizon is massive. It means agency owners can start redesigning their standard operating procedures around this manual UI today, knowing that they are building the foundation for fully automated cross-object management tomorrow. Exactly. It allows you to culturally adapt your team to the new relational model now, so when the workflow triggers finally unlock, your agency is already trained on how to leverage the visibility. This has been a phenomenal breakdown of the architecture. I mean, moving from a restrictive contacts-only system to full multi-object task associations is going to permanently kill the clone task, eliminate the silos between sales and operations, and frankly, make GoHighLevel operate like a truly enterprise-grade agency operating system. It really is a profound structural evolution for the platform. But, you know, as we wrap up, I want to leave you with the broader psychological implication of this update. Okay, let's hear it. This technology brilliantly solves a massive data visibility problem. But in doing so, it introduces a fascinating new human dynamic. If one single task can now live simultaneously in the sales pipeline, on the executive company dashboard, and in the operations team's custom object view, does this fundamentally change how your agency defines the ownership of a client deliverable? Oh, wow. The classic bystander effect, but applied to task management. Exactly. If the sales team, the customer success team, and the operations team all have equal real-time visibility and access to the exact same task, how do you, as an agency owner, ensure someone still takes ultimate responsibility? Yeah. When everyone can see the work, you run the very real risk that everyone assumes someone else is handling it. That is a brilliant piece of business psychology to end on. Technology can perfectly connect the relational dots of your database, but leadership still has to assign the driver. on. That is something every single agency owner needs to strategize around as they roll this architectural update out to their respective teams. Visibility does not automatically equal accountability. No. And speaking of rolling this out, remember, you do not have to just sit back and imagine how this impacts your workflows. You can get your hands dirty and test the limits of this architecture right now. Definitely do it. We have a free 30-day GoHighLevel trial, double the standard trial length, and that link is waiting for you in the show notes below. Click it, load up some sandbox data, and experience the death of the clone task for yourself. See how this changes your agency's efficiency today. You won't regret it. Thank you so much for taking this deep dive with us. Keep optimizing your systems, keep protecting those profit margins, and we will catch you on the next deep dive.