Sales Pipeline CRM

A custom Salesforce alternative for deal management, built entirely on Xano. Reps and managers work opportunities through a stage pipeline — with stage-driven probability, expected revenue, forecast categories, activities, stage history, and lead conversion — over a Kanban board and a forecast dashboard. Self-contained: it ships its own seed data and runs end to end with no Salesforce account or third-party credentials.

Sales teams pay per seat for Salesforce to do the core of deal management — a stage pipeline, weighted forecasting, activity tracking, and lead conversion — yet the logic that drives those numbers is locked inside a system you don't own and can't easily change. When you want a different stage model, a custom rotting-deal rule, or forecasting your own way, you're fighting the platform.

This template rebuilds that core as transparent Xano logic you own outright. Every Salesforce-mirrored behavior — how probability follows the stage, how ExpectedRevenue is computed, how forecast categories roll up, how stage history is recorded, how a lead converts — is a plain XanoScript function or endpoint you can read and edit. It's a working starting point for a CRM you control, not a black box, and it's modeled on Salesforce's documented behavior (sources below), not reverse-engineered from a live org.

backend/
  api/
    analytics/
      activity_feed_get.xs
      api_group.xs
      dashboard_stats_get.xs
      forecast_get.xs
    auth/
      api_group.xs
      login_post.xs
      me_get.xs
      signup_post.xs
    crm/
      accounts_get.xs
      accounts_post.xs
      activities_complete_post.xs
      activities_post.xs
      api_group.xs
      board_get.xs
      contact_roles_post.xs
      contact_roles_primary_post.xs
      contacts_get.xs
      contacts_post.xs
      deals_advance_post.xs
      deals_detail_get.xs
      deals_get.xs
      deals_lost_post.xs
      deals_post.xs
      deals_won_post.xs
      leads_convert_post.xs
      leads_get.xs
      leads_post.xs
      stages_get.xs
    seed/
      api_group.xs
      health_get.xs
      seed_post.xs
  function/
    advance_deal.xs
    attainment_band.xs
    calc_expected_revenue.xs
    convert_lead.xs
    create_deal.xs
    days_between.xs
    deal_alerts.xs
    forecast_rollup.xs
    lose_deal.xs
    win_deal.xs
  table/
    account.xs
    activity.xs
    contact.xs
    deal_stage_history.xs
    deal.xs
    lead.xs
    opportunity_contact_role.xs
    pipeline_stage.xs
    user.xs
  workflow_test/
    dashboard_and_convert.xs
    deal_lifecycle.xs
    rep_stage_guard.xs
  workspace/
    templates.xs

The pipeline itself is data, not code: a pipeline_stage table holds the ten standard Salesforce opportunity stages, each with a default probability, a forecast category, and is_closed/is_won flags — so you reshape the pipeline by editing rows, exactly as an admin edits the Opportunity Stage picklist in Salesforce. The Salesforce-mirrored logic lives in small, testable pieces:

• Stage-driven probability. Advancing a deal snapshots the target stage's default probability onto the deal; a rep can override it. Salesforce Probability is "implied, but not directly controlled, by the StageName field… you can override this field" (Opportunity object reference).
• Expected revenue. expected_revenue = amount × probability / 100, recomputed on every stage/probability change — Salesforce's ExpectedRevenue, "a read-only field that is equal to the product of the opportunity Amount field and the Probability" (same reference).
• Forecast categories + rollup. Each stage maps to a forecast category (Pipeline, Best Case, Commit, Omitted, Closed); the dashboard reports the cumulative columns — Open Pipeline = Pipeline+Best Case+Commit, Commit = Commit+Closed, etc. — as unweighted amounts (Forecast category mapping, cumulative rollup methods).
• Guarded transitions + stage history. Reps advance one stage at a time (managers may jump); each move writes a deal_stage_history row with days-in-previous-stage — Salesforce's OpportunityHistory, where "anytime a user changes the Amount, Probability, Stage, or Close Date… a new entry is added" (OpportunityHistory reference). IsClosed/IsWon are set by moving to the won/lost stage, mirroring how those flags are "directly controlled by StageName" in Salesforce.
• Attention alerts. Each open card surfaces the three Salesforce Kanban alerts — an overdue task, no open activities, or no activity for 30 days (Kanban view) — driven by the activity table and each deal's rolled-up last_activity_at (the most recent completed activity due date).
• Lead conversion. Converting a lead creates/links an account, a contact, and (optionally) an opportunity, then flags the lead converted with the created record ids — Salesforce's convertLead (convertLead API).
• Quota attainment. Per-rep closed-won vs a monthly/quarterly quota, bucketed into Salesforce Collaborative Forecasts' color bands — grey 0%, red 1–33%, orange 34–66%, green 67%+ (forecast quotas).

Honest caveat on the numbers. Salesforce does not publish an exact default probability for every stage; only a subset appears in its documentation. The seeded stage probabilities follow Salesforce's documented example mapping plus the commonly-cited defaults — in a real Salesforce org these are configurable data, not fixed constants.

Start with your coding agent. Paste the prompt below into a local MCP-capable coding agent — Claude Code, Cursor, Windsurf, and others. It installs the Xano CLI, connects Xano, and imports this template.

Start building in Xano: Access the prompt at https://go.xano.co/start-xano-with-template-skill and run it here with sales-pipeline-crm as your template.

The agent will walk you through the setup below.

1. Create a Xano workspace and import this template's backend/ export (or fork the repo and push it).
2. Load the demo data with one call:

curl -X POST "https://<your-instance>.xano.io/api:salescrm-seed/seed"

3. Open frontend/index.html in a browser. On first load it asks for your Xano instance base URL (e.g. https://<your-instance>.xano.io).
4. Sign in as a seeded user — morgan.lee@northwind.example (manager) or alex.chen@northwind.example (rep), password DemoPass1 — and work the Pipeline, Leads, and Forecast views.

api:salescrm-auth — authentication

api:salescrm-crm — accounts, contacts, leads, stages, deals, roles, activities

api:salescrm-analytics — pipeline analytics

api:salescrm-seed — demo data

• user — sales reps and managers (role flag + monthly/quarterly quota); the auth table.
• account — companies, owned by a user.
• contact — people at an account.
• lead — inbound leads with status/rating and the converted-record ids after conversion.
• pipeline_stage — the ten Salesforce opportunity stages: order, default probability, forecast category, and closed/won flags.
• deal — opportunities: amount, snapshot probability, expected revenue, stage, forecast category, status, and rolled-up last-activity date.
• opportunity_contact_role — the many-to-many link of contacts to a deal, with a role and a primary flag.
• deal_stage_history — one row per stage change (from/to stage, snapshots, days in previous stage) — the audit trail behind velocity metrics.
• activity — logged calls, emails, meetings, and tasks (open vs. completed) that drive the timeline and attention alerts.

The core deal logic lives in reusable functions (create_deal, advance_deal, win_deal, lose_deal, convert_lead) that the endpoints wrap as thin, auth-checking shells — so the tests exercise exactly the code path the API runs. The template ships its tests in backend/:

• Unit tests — embedded test blocks on the pure functions cover the math: expected-revenue, the cumulative forecast rollup, the quota color bands, the three Kanban alerts, and the day counter. Run with xano unit_test run_all.
• Workflow tests (backend/workflow_test/) — end-to-end flows against the seeded data through the shared logic functions: the full deal lifecycle (create → advance → win, asserting the probability snapshot, forecast category, and that a stage-history row is written at each step), the forecast rollup plus lead conversion, and the rep stage-skip guardrail. Run with xano workflow_test run_all.
• Live smoke — every published GET endpoint is checked reachable over HTTP after deploy.
• HTTP integration test (tests/api_smoke.py) — a black-box Python script that hits every endpoint over real HTTP with real auth tokens (the layer the XanoScript tests can't reach), asserting authentication + negatives, manager/rep role scoping, the deal math, the stage-skip guard and cross-owner 403, won/lost effects, one-primary-contact enforcement, lead conversion, and the analytics response shapes. Run it after loading the seed: python3 tests/api_smoke.py https://your-instance.xano.io.

All tests run unattended in a fresh workspace — this is a self-contained template, so no credentials are required.