> ## Documentation Index > Fetch the complete documentation index at: https://docs.get2dial.com/llms.txt > Use this file to discover all available pages before exploring further. # How Get2Dial works > The object model behind every call in Get2Dial, and the order you must configure it in to avoid dependency errors. Get2Dial's objects have a real dependency order, enforced by the product rather than suggested. A phone number cannot be trusted for inbound calls until its carrier is connected and approved; a routing rule cannot send a call anywhere until a destination exists; a campaign cannot dial until it has a carrier able to send calls out. Configuring things out of order is the most common cause of "nothing happens" during setup — this page is the map that prevents it. ## How it works Every call, inbound or outbound, depends on the same first link: a connected, approved [carrier](/voice/connect-a-carrier). From there, inbound and outbound branch: ```mermaid theme={null} flowchart TD A[Carrier] --> B[Outbound route] A --> C[Phone number] C --> D[Routing rule] D -->|business hours closed| H[Voicemail] D --> E[Queue] D --> F[IVR menu] D --> G[Ring group] F --> E E --> I[Agent] G --> I ``` An inbound call arrives on a **phone number**. A **routing rule** tied to that number sends the call to a destination: a **queue**, an **IVR menu** (which can hand off to a queue), a **ring group**, or **voicemail**. A routing rule can also carry a business-hours schedule — outside those hours the call falls back to a separate closed-hours destination instead. From a queue or ring group, the call reaches an **agent**. An outbound call works from the other direction. A **campaign** dials from a **lead list**, using an **outbound route** to select which carrier sends the call, and hands connected calls to agents through the queue the campaign is bound to. The campaign also needs **dispositions** so agents can record the outcome of each call. **Why the carrier sits at the root of both paths:** a phone number with no approved, inbound-capable carrier behind it will not ring, even with a perfectly configured routing rule — the platform will not trust inbound traffic for it. This fails silently rather than with an obvious error, which is why [Connect a carrier](/voice/connect-a-carrier) is the first task in every setup. ## When to use it Read this page once, before you configure anything, and come back to it whenever a call "does nothing" instead of failing with a clear error — that symptom almost always means a link in this chain is missing, not that a downstream setting is wrong. ## What it affects Configuring out of order produces confusing failures rather than helpful ones: a routing rule pointed at a queue with no members rings nothing; a campaign with no bound queue dials but never connects an agent; a phone number on an unapproved carrier looks configured but never receives a real call. Following the dependency order — carrier, then routes and numbers, then destinations (queues, IVR, ring groups), then routing rules, then agents — avoids all three. ## Limits and constraints There is no limit on how many carriers, routes, phone numbers, or routing rules a workspace can have. See [Limits and quotas](/reference/limits-and-quotas). ## Next steps