Skip to main content
F-5 · GTM Foundation · 100 XP · ~20 min
You’ve built a grid. You’ve read the data. Now you need to understand what’s actually happening when Bitscale runs — so you can design workflows that scale without breaking, debug problems when they occur, and know exactly what’s happening to your data at every step.

​
How Bitscale Executes a Grid

When you click Run, Bitscale doesn’t process rows top to bottom. It executes in layers: Layer 1 — Input resolution: Raw input columns are validated and normalized. Bad domains get flagged. Empty rows are skipped. Layer 2 — Enrichment execution: All enrichment columns run in parallel across rows. Row 1’s enrichment and row 500’s enrichment run at the same time. Layer 3 — Dependent columns: Columns that depend on enrichment output (AI columns, formula columns) run after their dependencies complete. Layer 4 — Output routing: Any configured outputs (CRM sync, Slack notification, export) fire after the grid is complete. Understanding this layer model is critical for debugging. If a formula column is empty, it’s because its dependency column is empty — not because the formula is wrong.

​
Column Dependency Mapping

Every column in a Bitscale grid has a dependency chain. Before building a complex grid, map it out: 
Input: Company Domain
  └── Enrichment: Employee Count (Clearbit)
  └── Enrichment: Industry (Clearbit)
  └── Enrichment: Tech Stack — CRM (BuiltWith)
        └── Formula: ICP Score (depends on above 3)
              └── AI: Personalized First Line (depends on ICP Score + all enrichment)
                    └── Output: Export to Instantly (depends on First Line)
If BuiltWith fails for a row, the ICP Score will be incomplete. If ICP Score is incomplete, the First Line prompt runs with less context. Build your grids so that missing data degrades gracefully rather than causing complete failures.

​
Designing for Scale: Five Rules

Rule 1 — Validate inputs early. Before enrichment runs, add a formula column that checks whether the domain is valid (not null, has a TLD, not a personal email domain). Filter out bad rows before they waste API calls. Rule 2 — Cache enrichment results. If you run the same company through the grid twice, it shouldn’t make a new API call. Enable caching on enrichment columns to avoid duplicate costs and rate-limit issues. Rule 3 — Use conditional AI columns. Don’t run an AI column on every row. Add a condition: only run the first-line generation if ICP score >= 5. This cuts AI costs by 60–80% and keeps quality high. Rule 4 — Separate enrichment grids from activation grids. Keep your “find and score” grid separate from your “personalize and send” grid. This modularity means you can rerun enrichment without triggering outreach, and vice versa. Rule 5 — Log everything. Add a Run Timestamp column and a Status column to every grid. When something breaks at 2am, you want to know exactly which rows failed and when.

​
Triggers: How Grids Start Running

Grids don’t have to be run manually. Bitscale supports several trigger types:
Trigger TypeUse CaseExample
ManualOne-time or ad hoc runsList for a conference
ScheduledRegular cadenceNew ICP leads every Monday morning
WebhookEvent-driven from external systemNew deal created in CRM → enrich contact
APIProgrammatic trigger from your codebaseForm fill → instant enrichment
Most mature GTM systems combine all four. The Monday enrichment schedule fills the top of the funnel. The CRM webhook handles individual inbounds. The API trigger handles product-led signals.

​
Debugging Checklist

When a grid run produces unexpected results:
  1. Check input quality — null domains? Duplicate rows?
  2. Check enrichment coverage — which columns have high null rates?
  3. Check dependency order — is the formula column running before its dependencies?
  4. Check condition filters — are AI columns skipping rows they shouldn’t?
  5. Check rate limits — did the run hit an API rate limit and stop mid-grid?
Most issues are caused by #1 (bad input) or #5 (rate limits). Fix your input data first. If rate limits are the issue, break the grid into smaller batches.
Quick Check: Draw the dependency chain for your F-3 grid from memory. Can you identify which column, if it failed, would have the most downstream impact? That column is your single point of failure — it deserves the most validation logic.

​
F-5 Challenge: Design a Workflow Diagram (+100 XP)

Take your F-3 grid and draw its full dependency chain. Map every column, its type (input/enrichment/AI/formula), and its dependencies. Identify one single point of failure and describe how you’d add a fallback.

Submit F-5 Challenge →

Submit your workflow dependency diagram and failure point analysis. +100 XP on approval.

Next: Foundation Knowledge Check →

Lock in everything from the Foundation track before moving to Outbound Automation.