GTM tech stack architecture: what each system should do
Design a GTM stack around data authority, business-rule ownership, automation, and measurement, with CRM-first and warehouse-centered tradeoffs.
On this page
- Separate authority, policy, and execution
- Map capabilities before products
- Be specific about source of truth
- CRM-centered automation
- Dedicated orchestration and small services
- Functional tools can keep local rules
- Choose execution by timing and consequence
- Warehouse-centered architectures
- AI outputs need an authority contract
- Example: one rule across several systems
- Record the architecture decision
- FAQ
Design a GTM tech stack by assigning responsibilities: which system owns each fact, which owner controls each business rule, and where the work executes. The matrices below make those choices visible before another tool is added.
I prefer concentrating shared business logic in as few places as practical. I have had good results using Salesforce as the operational center. That is a preference shaped by my environment, not a requirement for every company.
The GTM system anatomy explains the parts of the system. This reference allocates those parts to technology and names the tradeoffs.
Separate authority, policy, and execution
Three decisions are easy to collapse into one.
| Decision | Question | Example |
|---|---|---|
| Data authority | Which source is trusted for this fact? | CRM owns account assignment; billing owns an invoice |
| Policy ownership | Who approves the business rule? | Sales and RevOps agree which requests qualify |
| Execution location | Which service performs the step? | Native CRM automation or an external worker |
One platform can support several responsibilities. Several platforms can also execute one approved policy. The problem is uncoordinated authority, not the mere presence of more than one application.
Map capabilities before products
A small organization might use a CRM, its native automation, and a few integrations. A company joining extensive product, billing, and revenue data may need a more substantial data platform. Start with the work that must happen, not the number of boxes in the architecture.
Be specific about source of truth
I like one clear operational home for customer and revenue work. That does not mean the CRM must originate or control every fact the business uses.
For example, a possible authority map is:
| Fact | Authority in this example | Treatment elsewhere |
|---|---|---|
| Account owner | CRM | Read or cache; request approved reassignment |
| Message delivery | Sending platform | Copy delivery evidence with its event timestamp |
| Product usage | Product event source | Aggregate for account context with freshness visible |
| Invoice | Billing system | Reference or synchronize without redefining the invoice |
| Lifecycle | Agreed CRM fields | Suggest transitions through the approved policy |
Record which field or event is authoritative, the identity used to join systems, expected freshness, and the conflict rule. A copied value needs a way to show when it no longer reflects its source.
The metric ownership reference applies the same discipline to reported numbers.
CRM-centered automation
I prefer native CRM automation when it can express the rule safely and the team can operate it. Keeping the work near shared records can reduce external handoffs and make the logic easier for administrators to inspect.
Check the actual capabilities available in the organization's Salesforce or HubSpot environment. Do not assume a particular license, execution limit, connector, or action is included. This article describes architectural choices, not a current product-tier comparison.
The tradeoff is coupling. Business rules implemented deeply inside a CRM take work to move elsewhere.
I previously maintained a separate marketing-automation layer and later moved much of its logic into Salesforce. That reduced dependence on the marketing platform while increasing dependence on Salesforce. It is a useful tradeoff to account for in any future CRM migration.
Concentrating logic can improve consistency, but it also concentrates the consequence of a mistake. Keep access controls, tests, recovery, and capacity planning around the centralized layer.
Dedicated orchestration and small services
An orchestration platform coordinates work across systems. A tool such as n8n, or a maintained custom service, can separate execution from the CRM and support workflows that native capabilities do not cover well.
That creates another operating responsibility. The service needs credentials, deployment controls, job history, failure handling, and an owner. It can reduce CRM-specific coupling without making the entire workflow portable automatically; record models and connectors can still be platform-specific.
A repository plus a server can be enough for some workflows. The repository holds versioned code; a server, function, or worker runs it. Someone still needs to manage scheduling or events, retries, secrets, monitoring, and recovery.
For an example of the infrastructure behind a dedicated orchestrator, n8n's queue-mode documentation separates trigger handling from worker execution and describes the supporting queue and database. The architectural independence comes with services to operate.
Functional tools can keep local rules
Marketing, sales engagement, customer-success, and enrichment tools may each have useful native automation. Use those capabilities where the behavior belongs to that tool.
For example, a messaging platform can manage delivery and its own suppression enforcement. It should not independently invent a second company-wide lifecycle definition. Conversely, centralizing lifecycle authority does not justify removing protective checks from the sending platform.
I aim for one approved policy with documented implementations at the boundaries that need it. Avoid several unrelated copies of the same rule drifting without anyone noticing the difference.
Choose execution by timing and consequence
A scheduled cleanup and an inbound response process have different latency requirements. Define how late a run may be, what happens after a failure, and whether waiting for the next schedule is acceptable.
| Work pattern | Design considerations |
|---|---|
| Periodic cleanup or reporting | Scheduling window, safe reruns, completion evidence, and missed-run alerts |
| Time-sensitive handoff | Event capture, durable work state, acknowledgement, retry limits, and escalation |
| High-volume processing | Capacity, rate limits, concurrency, cost, and backpressure |
| High-consequence action | Authorization, preview or approval, scope limits, and recovery |
Do not assume a scheduler guarantees exact timing. GitHub documents that scheduled Actions can be delayed or dropped under load. That matters when evaluating an implementation for a time-sensitive workflow.
A dedicated automation product is not automatically reliable. A small service is not automatically unsuitable. Judge the operating behavior against the requirement.
Warehouse-centered architectures
A warehouse can be valuable when the business needs historical analysis, product and revenue joins, reusable analytical models, or large-scale transformations. Google's BigQuery overview provides one concrete example of an analytical platform with data storage, query processing, and business-intelligence capabilities.
In a warehouse-centered design, approved account attributes or segments can be calculated there and synchronized into tools used by revenue teams. This can centralize cross-source logic. It also requires clear identity, freshness, write authority, and conflict handling at the destination.
My preference for a CRM operational center does not make warehouse-derived facts less valid. Choose the authority that matches the fact and define how operational users receive it.
A warehouse can support redundancy or recovery when designed for it. It should not be purchased merely because a larger company has one, or dismissed because a smaller CRM-first system is adequate elsewhere.
AI outputs need an authority contract
An LLM can return a summary, extracted attribute, classification, or draft. Decide where that output belongs and what is allowed to happen because of it.
| Output | Suggested treatment |
|---|---|
| Research summary | Retain sources, freshness, and generated status |
| Fit recommendation | Store separately from an approved disposition |
| Extracted attribute | Treat as a candidate until the required evidence is satisfied |
| Draft message | Present for review or send only through the authorized workflow |
| Proposed CRM change | Enforce permissions and action policy before writing |
A human-owned assessment should remain distinguishable from an AI assessment. Agreement and disagreement can both be useful; neither should silently overwrite the other. Read AI-generated CRM fields for the field-level contract.
Example: one rule across several systems
For example, RevOps and Sales approve inbound eligibility. The CRM holds the current request state. An external worker gathers evidence and returns a recommendation. The CRM records the approved disposition and starts seller follow-up.
- 1Record the request in the operational system
- 2Send stable identity and the approved rule version
- 3Gather the required evidence
- 4Evaluate and return a result or explicit exception
- 5Apply the permitted state change
- 6Reconcile execution and measure the business handoff
Specify the fields each service may update, how duplicate delivery is handled, what happens if the record changes during processing, and who investigates an unfinished handoff. The handoff contract and reconciliation reference cover those details.
Record the architecture decision
Use this template for each important capability rather than adopting one blanket rule for the entire stack.
| Decision field | What to document |
|---|---|
| Outcome and owner | The business result and accountable stakeholder |
| Data authority | The source and fields trusted for each fact |
| Policy authority | Who approves changes and where the rule is documented |
| Execution | Which systems perform which steps |
| Constraints | Timing, volume, access, available licenses, and operating skills |
| Recovery | Retry behavior, exception owner, stop control, and restoration needs |
| Alternatives | Configure, connect, buy, or build, with reasons for the choice |
| Carrying cost | Maintenance, monitoring, vendor dependence, and migration work |
| Review trigger | What business or platform change would reopen the decision |
The buy/configure/connect/build reference applies the comparison to data-quality capabilities. None of the four choices removes the need for ownership and ongoing operation.
Before a migration or consolidation, use the GTM systems technical-debt audit to verify which dependencies still earn their keep. When the business problem itself is unclear, start with GTM engineering problem-solving before selecting an architecture.
FAQ
- What should be the source of truth in a GTM tech stack?
- Name the authority for each important fact. I prefer the CRM as the operational center for ownership, lifecycle, and pipeline when it fits the business. Billing, product, and messaging systems can still own their originating facts. A warehouse-centered model is another valid choice when its data and operating requirements justify it.
- Should GTM automation live in the CRM?
- It can when the CRM has the capabilities, capacity, and operating controls the workflow needs. Centralizing logic can simplify inspection but increases CRM dependence. External orchestration can separate execution from the CRM while adding another service to maintain.
- Does a data warehouse replace a CRM backup?
- Do not assume an analytical copy is a recoverable backup. Define retention, deletion behavior, permissions, metadata coverage, and a tested restore path separately. A warehouse may support recovery, but that requires an explicit design.
- Do I need a dedicated automation platform?
- Not always. Native automation or a maintained service can be enough. Choose by timing, volume, integration needs, ownership, and recovery requirements. A code repository stores the implementation; it still needs an execution environment.