Help & Documentation

This overview introduces the inveazy platform from the outside in — what visitors see first, how you sell (web, desk, or counter), field and rental scenarios, then the signed-in apps your team uses every day. For a compact feature list see /about. For installing the server see Installation & Docker.

What is inveazy?

inveazy is a business platform that runs many separate company workspaces on one installation. Each workspace has its own users, data, branding, and enabled apps. You turn modules on under Admin → Integrations → Applications, then assign them to roles so people only see what they need.

Your public website

Before anyone signs in, guests land on your organization’s public site. Under Public site branding you can:

• Choose a theme (colors, header, and footer chrome) so the site matches your brand.
• Customize the landing page — hero image and copy, company names, and whether marketing sections show.
• Add ordered landing blocks (HTML sections after the hero) and optional custom footer content.
• Turn on or off the public blog and shop, and control what appears in the header.

Customer installs can hide platform marketing and keep only their own hero, blocks, shop, and blog. Signed-in users always go to the hub launcher, not the marketing home.

Ecommerce — pick the channel that fits the sale

inveazy covers how you sell, not just an online cart. The same customer, product, sales-order, invoice, and payment rails can serve a wholesale buyer, a desk quote, a walk-up at the counter, or a mix. Turn on the modules you need under Integrations, then use the channel that matches the scenario.

1. B2B / public web storefront

Customers browse your catalog at /store, check out with Stripe Checkout (or account terms), and staff fulfill from Web orders — pick, ship, and invoice. Best when buyers order online and you ship from the warehouse.

• B2B wholesale — registered buyers order from the catalog; warehouse ships and bills through supply chain.
• Lighter catalog / shop — sell products with a simpler catalog when you do not need every warehouse screen.
• Guest or account checkout — card prepaid online, or invoice later when payment terms allow.

Help: Storefront overview · Web orders.

2. Desk sales — quotes, sales orders, and invoices

Inside the hub, sales and ops enter quotes and sales orders, then ship and bill with customer invoices. Buy-side purchase orders replenish stock. Best for phone/email deals, negotiated pricing, and B2B that never uses the cart.

• Quote → SO → ship → invoice — classic sell-side document chain (End-to-end workflows).
• Invoice pay link — customer pays an open invoice online with the same commerce Stripe keys.
• PO → receive — buy-side replenishment so on-hand stays accurate for every sell channel.

3. Counter POS — in-person till

Counter POS (/pos) is the fullscreen till for retail counters, farm stands, cafés, and showrooms. Clerks attach a customer (or walk-up), add products and/or services, then take cash or card on a Stripe Reader (S700/S710). Paid sales still create a sales order and paid invoice — the same documents as web and desk — so AR, inventory, and QuickBooks stay consistent.

• In-person paid now — tap/insert/swipe or cash; optional tips; Hold / Open tickets for busy counters.
• Services menus — non-SKU lines (labor, delivery, add-ons) from Settings → Services.
• Ship from the till — when shipping is enabled, use a registered customer’s ship-to ZIP; walk-ups stay takeaway.
• Returns at the counter — look up a paid order and restock or refund (POS returns).

Help: Counter POS · Card readers. Terminal uses the same Integrations → Payments keys as online checkout — no extra Terminal key field.

Which channel when?

• Buyer is remote and self-serves — web storefront.
• Sale is negotiated or phone-in, then warehouse ships — desk quote / sales order.
• Buyer is at your counter and pays now — Counter POS.
• Same business, mixed day — use all three; they share customers, SKUs, and invoices. Capital equipment you own (not for resale stock) stays in Assets Tracking.

Card money for storefront, invoice pay links, and POS Terminal all use your Stripe commerce account under Integrations. Inventory and fulfillment stay in supply chain so every channel reports the same way.

Rentals and consignments

Not everything you handle is a simple “sell from stock” product:

• Rentals — Place owned capital equipment out as a rental on the Assets Tracking schedule (with job site and consignment placements as well). Inspect units at the dock with Checkout / check-in. Deposits and full rental checkout on the Counter POS till are still on the Roadmap.
• Consignments — Track gear sitting at a customer or vendor site as a consignment placement in Assets Tracking, or manage inventoriable consignment products in supply chain when the stock itself is bill-and-replace inventory.

Products you sell refill from inventory. Expensive owned units live in Assets Tracking so they never clutter warehouse on-hand counts.

CRM

CRM is where you manage people and the sales pipeline: organizations, accounts, contacts, leads, opportunities, activities, and deals. Use it to answer who you sell to, which deals are open, and what happened last. When a deal becomes an order to fulfill, work continues in supply chain.

Project management

Project management plans delivery work: projects, work items, sprints, a Kanban board, and a Gantt view. It is for schedules and tasks — not warehouse stock and not payroll.

Supply chain management

Supply chain (SCM) is the operational core for buying, stocking, selling, and shipping goods. Help groups it the way teams work:

• Buy side — Vendors, products, categories, purchase orders, receipts, warehouses, bins, on-hand, transfers, cycle counts, reorder alerts, and the mobile scanner.
• Sell side — Customers, quotes, sales orders, shipments, returns, and backorders. See End-to-end workflows for the full document chain.
• Storefront — Public shop and the staff web-order queue.
• Counter POS — In-person till (Counter POS help); sales land on the same SO/invoice path.
• Accounting — Covered next; it sits with SCM menus because invoices and bills follow the same documents.

Dashboards for sales, purchasing, and inventory give managers read-only KPIs without editing documents.

Accounting, QuickBooks, and Stripe

Accounting records customer invoices, vendor bills, income and expense cash entries, and posts to a local general ledger. You can release AR and AP export batches and review P&L on the financial dashboard.

QuickBooks Online syncs master data and documents so many businesses keep QuickBooks as the system of record after export. Stripe handles platform billing where applicable, customer Checkout on the storefront and invoice pay links, and Terminal card readers on Counter POS — configure commerce keys and Checkout webhooks under Integrations.

Tool sets, BOMs, and Assets Tracking

Tool sets (bill of materials recipes) define what belongs in a standard toolbox, kit, or reorder pack. Copy a recipe onto a capital asset when you build a real unit. Assets Tracking then manages those units: registry, dock inspection, schedule and map, maintenance, and reports. Small parts and disposables stay in products and inventory; the physical toolbox is a capital asset.

Signing in and finding your way

Open your organization’s URL and sign in with the email and password from your administrator. If you belong to more than one workspace, pick one after login. After sign-in:

• The hub launcher shows tiles for every app enabled for you.
• Top-bar menus group CRM, projects, supply chain, Assets Tracking, Hub apps, and Admin.
• Dashboards (/dashboard) are analytics only — pipeline, projects, finance, and SCM.
• This Help library matches those menus; Roadmap, Changelog, and the glossary live under Getting started.

Hub apps (files, notifications, calendar, blog) and the workspace assistant support day-to-day collaboration and AI help inside the platform.

Where to go next

• Brand the public site — Public site branding
• Sell online — Storefront and Stripe
• Sell at the desk — Quotes, Sales orders, Invoices
• Sell at the counter — Counter POS and card readers
• Win the deal first — CRM
• Run the warehouse — SCM overview and buy-side topics
• Close the books — Accounting and QuickBooks
• Track capital gear — Assets Tracking overview
• See what is coming — Roadmap and Changelog

This guide is for the person installing inveazy for an organization. Everyday users do not need any of this.

What you are setting up

1. SQL Server — your own server, Azure SQL, or SQL Server in a Docker container.
2. Database — create AppHubDb and install AppHubDb.dacpac with SSMS and SqlPackage.
3. inveazy — run docker-compose.web.yml with a connection string to that database.

Docker runs the website only. SQL Server can be Docker too, but the database install is still done with SSMS — not by starting the web container.

Installation order

1. Prepare the app server — Docker (and optional stack manager).
2. Run SQL Server — existing server or Docker.
3. Connect with SSMS — create the database; Local recovery SIMPLE.
4. Install the DACPAC — SSMS + SqlPackage from Command Prompt.
5. Deploy inveazy — compose file + connection string.
6. Optional production settings — public URL, Stripe, QuickBooks, SMTP.

Step 1 — Prepare the app server

This machine runs the inveazy website container. It must be able to reach SQL Server on the network (port 1433).

• Docker Engine + Compose v2 — Install Docker
• Stack manager (optional) — Dockhand, Dockge, or Portainer
• Registry access — pull the apphubweb image (docker login to your registry)

docker --version
docker compose version

Step 2 — Run SQL Server

Pick one path below. Skip the Docker section if you already have SQL Server or Azure SQL.

Option A — SQL Server in Docker

Run Microsoft SQL Server 2022 in a container on your Linux server (or the same machine where inveazy will run). Data is kept in a Docker volume so it survives container restarts.

Start SQL Server with Docker Compose — create a file named docker-compose.sql.yml on the server:

services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2022-latest
    container_name: apphubdb-sql
    hostname: apphubdb-sql
    restart: unless-stopped
    ports:
      - "1433:1433"
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: "YourStrong!Passw0rd"
      MSSQL_PID: "Developer"
    volumes:
      - apphubdb_sql_data:/var/opt/mssql

volumes:
  apphubdb_sql_data:

Replace YourStrong!Passw0rd with a strong password that meets SQL Server policy (upper, lower, number, symbol). Save that password — you need it for SSMS and SqlPackage as login sa.

From a terminal on the server, in the folder with that file:

docker compose -f docker-compose.sql.yml up -d

Wait about 30–60 seconds for SQL Server to finish starting. Check status:

docker ps
docker logs apphubdb-sql

When ready, the logs show SQL Server is accepting connections. The repo also has docker-compose.yml with the same SQL service if you prefer that file.

Connect from SSMS (Windows PC):

• Server name: YOUR_SERVER_IP,1433 — the LAN IP of the Docker host (e.g. 10.0.0.128,1433). If SSMS runs on the same machine as Docker, try localhost,1433.
• Authentication: SQL Server Authentication
• Login: sa
• Password: the MSSQL_SA_PASSWORD you set above
• On the login dialog, open Options >> → check Trust server certificate (common for Docker / lab SQL).

If connection fails: confirm port 1433 is open on the server firewall and that docker ps shows the container running.

Option B — Existing SQL Server or Azure SQL

Use SQL you already manage — a Windows SQL instance, a VM, or Azure SQL Database. Connect with SSMS the way you normally do (server admin login). Ensure the app server can reach the instance on port 1433 and that firewall rules allow the inveazy host.

Step 3 — Connect with SSMS and create the database

On a Windows PC, open SSMS and connect as SQL administrator (sa for Docker SQL, or your usual admin login).

1. Connect Object Explorer to your server (see Option A for Docker connection details).
2. Open a New Query window connected to master.
3. Run:

CREATE DATABASE AppHubDb;

On Azure SQL, create AppHubDb in the Azure portal instead if you prefer. Refresh Object Explorer and confirm AppHubDb appears under Databases.

Local / Docker SQL — recovery model (important)

New databases on SQL Server (including Docker) often inherit FULL recovery from the model database. Without regular transaction log backups, the log file can grow to many gigabytes over weeks of publishes and testing — while the data file stays small.

For Local LAN / Docker / self-hosted lab installs where you do not need point-in-time restore from log backups, set SIMPLE recovery right after create (and on any existing local DB that has already ballooned):

ALTER DATABASE AppHubDb SET RECOVERY SIMPLE;
-- Optional reclaim after switching (local only):
-- USE AppHubDb;
-- DBCC SHRINKFILE (N'AppHubDb_log', 128);

Replace AppHubDb with your database name if different (provisioned customer DBs often use the workspace slug). Local customer provision scripts apply RECOVERY SIMPLE automatically for new databases.

Azure SQL: leave FULL recovery. Azure manages log truncation with automated backups — do not switch Azure databases to SIMPLE for this reason.

Step 4 — Install AppHubDb.dacpac (SSMS + SqlPackage)

The DACPAC creates all tables, security, and seed data, plus the contained user AppHubUser. inveazy does not do this step for you.

The DACPAC needs a password variable (AppHubUserPassword). Run SqlPackage from Command Prompt on the SSMS PC (SqlPackage installs with SSMS). The SSMS Deploy Data-tier Application wizard cannot set that variable.

You need:

• AppHubDb.dacpac — from your maintainer, or build AppHubDb/AppHubDb.sqlproj in Visual Studio (Release), or download the AppHubDb-build pipeline artifact
• A password you choose for AppHubUser — save it; the inveazy connection string uses the same password

Run SqlPackage from Command Prompt:

1. Open Command Prompt on the Windows machine where SSMS is installed.
2. Find SqlPackage.exe — common paths:
   • C:\Program Files\Microsoft SQL Server\160\DAC\bin\SqlPackage.exe
   • C:\Program Files\Microsoft SQL Server\150\DAC\bin\SqlPackage.exe
   Or download from Microsoft SqlPackage.
3. Run (edit paths and passwords for your server):

"C:\Program Files\Microsoft SQL Server\160\DAC\bin\SqlPackage.exe" ^
  /Action:Publish ^
  /SourceFile:"C:\path\to\AppHubDb.dacpac" ^
  /TargetConnectionString:"Server=YOUR_SERVER_IP,1433;Initial Catalog=AppHubDb;User ID=sa;Password=YOUR_SA_PASSWORD;Encrypt=True;TrustServerCertificate=True" ^
  /Variables:AppHubUserPassword="YOUR_APPHUB_USER_PASSWORD" ^
  /p:RegisterDataTierApplication=false

For Docker SQL, use sa and your container MSSQL_SA_PASSWORD. For Azure SQL, use your server admin login and TrustServerCertificate=False.

Wait for Successfully published database. If publish fails, close other SSMS query tabs that have AppHubDb open and try again.

Confirm in SSMS:

1. Expand AppHubDb → Tables — you should see many tables.
2. File → Connect Object Explorer (second connection).
3. Login: AppHubUser. Password: your AppHubUserPassword.
4. Options >> → Connect to database = AppHubDb (not master).
5. Click Connect. If this works, inveazy will connect too.

Alternative: Visual Studio — open AppHubDb.sqlproj, Publish, set SqlCmd AppHubUserPassword in the publish dialog.

More detail: AppHubDb/ReadMe.md

Step 5 — Deploy inveazy (compose file + connection string)

Paste docker-compose.web.yml into your stack manager and set:

• APPHUBWEB_IMAGE — e.g. myregistry.azurecr.io/apphubweb:latest
• ConnectionStrings__DefaultConnection — points at AppHubDb on your SQL Server

Dockhand / Dockge / Portainer: new stack → paste YAML below → add variables → deploy.

Terminal:

docker compose -f docker-compose.web.yml up -d

docker-compose.web.yml

Use the file from the repo root (preferred). Essential shape:

services:
  apphubweb:
    image: ${APPHUBWEB_IMAGE}
    pull_policy: always
    container_name: apphubweb
    restart: unless-stopped
    ports:
      - "${WEB_PORT_SPEC:-18548:5148}"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      ASPNETCORE_URLS: http://+:5148
      ASPNETCORE_ENVIRONMENT: "${ASPNETCORE_ENVIRONMENT:-Production}"
      Web__TrustForwardedHeaders: "${Web__TrustForwardedHeaders:-true}"
      Web__ShowDevHub: "${Web__ShowDevHub:-true}"
      Web__EnableOpenApiDocs: "${Web__EnableOpenApiDocs:-true}"
      DataProtection__KeysPath: "${DataProtection__KeysPath:-/app/dpkeys}"
      ConnectionStrings__DefaultConnection: "${ConnectionStrings__DefaultConnection}"
      # Ops-only local provision (default off). Leave false on customer stacks.
      Provision__Enabled: "${Provision__Enabled:-false}"
      Provision__ListenerUrl: "${Provision__ListenerUrl:-}"
      Provision__SharedSecret: "${Provision__SharedSecret:-}"
      Provision__DefaultHostPort: "${Provision__DefaultHostPort:-10150}"
    volumes:
      - apphubweb_dataprotection_keys:/app/dpkeys

volumes:
  apphubweb_dataprotection_keys:

Provision install (ops only): Admin → Provision is available only on inveazy.com, hvt.inveazy.com, and hivoltech.com when Provision__Enabled=true and the host listener is running (deploy/docker-compose.provision-listener.yml). Customer slug stacks and localhost do not show the page (404). Do not copy Provision secrets into customer Dockhand env. Details: repo deploy/PROVISION-LOCAL.md.

Connection string — SQL Server in Docker on the same host as inveazy:

ConnectionStrings__DefaultConnection=Server=10.0.0.128,1433;Database=AppHubDb;User Id=AppHubUser;Password=YOUR_APPHUB_USER_PASSWORD;Encrypt=True;TrustServerCertificate=True;MultipleActiveResultSets=true

Use the server’s LAN IP (not localhost) — from inside the inveazy container, localhost means the container itself, not the SQL container. Replace 10.0.0.128 with your host’s IP.

Connection string — Azure SQL:

ConnectionStrings__DefaultConnection=Server=tcp:yourserver.database.windows.net,1433;Database=AppHubDb;User Id=AppHubUser;Password=YOUR_APPHUB_USER_PASSWORD;Encrypt=True;TrustServerCertificate=False;MultipleActiveResultSets=true

Test: http://127.0.0.1:18548 on the app server. Do not delete apphubweb_dataprotection_keys on redeploy.

Step 6 — Dockhand environment block (production)

Step 5 only needs APPHUBWEB_IMAGE and ConnectionStrings__DefaultConnection to get running. When you go live, paste the block below into your stack manager’s Environment panel (Dockhand, Dockge, or Portainer). Use the same variable names — no .env file is required on the server.

Replace every CHANGE_ME and example URL with real values for this customer. Never commit this block with live secrets to Git.

If SQL Server runs in Docker on the same host, set TrustServerCertificate=True in the connection string (as in Step 5). Azure SQL uses TrustServerCertificate=False.

# Required — replace yoursite.com / YOUR_SLUG with this install's values
APPHUBWEB_IMAGE=myregistry.azurecr.io/apphubweb:latest
ASPNETCORE_ENVIRONMENT=Production
ConnectionStrings__DefaultConnection=Server=YOUR_SQL;Database=YOUR_SLUG;User Id=AppHubUser;Password=CHANGE_ME;Encrypt=True;TrustServerCertificate=False;MultipleActiveResultSets=true

# Site URL + proxy (customer public hostname)
Web__PublicBaseUrl=https://yoursite.com
Web__TrustForwardedHeaders=true
Web__ShowDevHub=false
Web__EnableOpenApiDocs=false
Web__DisableSandboxSeededDemoLogins=true
DataProtection__KeysPath=/app/dpkeys

# Host email (optional if the workspace uses custom SMTP in Admin → Integrations)
Smtp__Host=smtp.mailersend.com
Smtp__Port=587
Smtp__Ssl=true
Smtp__User=CHANGE_ME
Smtp__Password=CHANGE_ME
[email protected]
Smtp__FromName=YOUR_COMPANY

# Stripe commerce — omit this whole block from Dockhand for customer installs.
# Enter secret, publishable, and webhook signing secrets in the app:
#   Admin → Integrations → Providers → Payments
# (Do NOT paste platform / inveazy subscription keys.) Uncomment stack Stripe__* only if you
# intentionally drive checkout from compose env instead of Integrations.
# Stripe__SecretKey=
# Stripe__PublishableKey=
# Stripe__WebhookSecret=
# Stripe__InvoiceCheckoutSuccessUrl=/pay/invoice?success=1&session_id={CHECKOUT_SESSION_ID}
# Storefront catalog workspace (config, not Integrations) — Core_Tenant.Slug for /store:
# Web__Store__CommerceTenantSlug=tenantname   # this install's workspace slug; not sandbox

# QuickBooks — Intuit OAuth app for this install (tenant Connects company in Admin → Integrations)
QuickBooks__ClientId=CHANGE_ME
QuickBooks__ClientSecret=CHANGE_ME
QuickBooks__Environment=production
QuickBooks__RedirectUri=https://yoursite.com/api/integrations/quickbooks/callback
QuickBooks__WebhookVerifierToken=CHANGE_ME

# Optional
ConnectionStrings__AzureStorage=DefaultEndpointsProtocol=https;AccountName=CHANGE_ME;AccountKey=CHANGE_ME;EndpointSuffix=core.windows.net
Mapbox__AccessToken=pk.CHANGE_ME

# Provision__* — omit on customer installs (defaults stay false). Ops hosts only: see note under docker-compose.web.yml.

Commerce Stripe on a dedicated install belongs to that customer — enter it under Admin → Integrations → Providers → Payments (and omit the Stripe__* block from Dockhand). Do not copy Hivoltech / inveazy platform keys. Copy the webhook URL from that Payments tab into the Stripe Dashboard and select commerce events (checkout.session.completed required; invoice payment events recommended — not subscription events). QuickBooks ClientId/Secret stay in env; the tenant still Connects their QBO company under Integrations → Providers → Accounting.

What each section does is documented in Prod.md at the repo root. Variable names only (no secrets): .env.web.example.

Check that it works

1. inveazy logs show no SQL errors.
2. http://127.0.0.1:18548 loads.
3. Sign-in works (change demo passwords before go-live).
4. Add users under Admin → Users.

Common problems

• SSMS cannot connect to Docker SQL — check docker ps, firewall on port 1433, use YOUR_SERVER_IP,1433, enable Trust server certificate.
• inveazy cannot connect but SSMS can — connection string must use the host LAN IP, not localhost, when SQL and web are both in Docker on the same machine.
• Login failed for AppHubUser — include Database=AppHubDb; password must match AppHubUserPassword from SqlPackage.
• DACPAC not installed — publish AppHubDb.dacpac before starting inveazy.
• Image pull fails — docker login; APPHUBWEB_IMAGE must not include https://.

See also production.md, Prod.md, and AppHubDb/ReadMe.md.

Tenant Admin is the platform-owner lane in inveazy. Users with the TenantAdmin role can provision workspaces, connect external services, set operational letterhead, and control the public marketing site. If you only manage users and roles inside one workspace — without provisioning new tenants — you may be an Admin instead; see Admin menu overview.

These screens still live under the top-bar ADMIN megamenu, but the help library groups them here so Tenant Admins can find platform tasks without wading through dashboard analytics. The ADMIN dropdown’s Organization and Platform & help columns map here; Workspaces (users, roles) and Dashboards are under Admin; marketing appearance is its own Public site branding help group.

Topics in this group

• Tenant workspaces — catalog of workspaces you administer
• Self-registration — per-workspace toggle on workspace detail (Demo, pilots, etc.)
• New tenant workspace — provision another isolated tenant
• Multitenancy — isolation, TenantId scoping, and terminology
• My organization — letterhead on POs, invoices, and operational PDFs
• Integrations — applications, Stripe, QuickBooks, SMTP, AI, read-only SQL

Public marketing appearance is documented under the sidebar group Public site branding (same screen in the ADMIN megamenu’s Public site column).

Typical onboarding order

1. Understand Multitenancy and open Tenant workspaces.
2. Provision customer workspaces via New tenant workspace (or the first-run setup wizard on a fresh install).
3. Switch into the workspace and enable modules under Integrations → Applications.
4. Set My organization letterhead before issuing SCM documents.
5. Connect Stripe, QuickBooks, and SMTP on the same Integrations page.
6. Configure Public site branding if you use the marketing landing page.
7. Invite users via User manager (documented under Admin).

TenantAdmin and Admin both see the ADMIN menu; individual links are hidden when your role lacks permission.

Admin → ADMIN → Tenant workspaces (/admin/tenants) lists every workspace (tenant) you administer on this inveazy install. This screen is for TenantAdmin only. It is one of the most important concepts to understand: a workspace is not a CRM account or customer company — it is the isolated container that holds all of your team's CRM accounts, products, users, and settings.

One physical inveazy deployment can host many workspaces. A software vendor might run one install for fifty customers, each with their own workspace slug and data. A single company might use one workspace for production and another for training. Each workspace has its own module toggles, roles, integrations, and document number sequences. Data never mixes between workspaces unless a platform operator explicitly copies it outside the app.

From the catalog you can open a workspace detail page to see its slug, enabled modules, user list, and self-registration settings. Use the workspace switcher in the top bar to change which workspace you are signed into; the tenant catalog is the map of workspaces you control.

Demo / SandBox and customer workspaces

Fresh installs seed only SandBox (sandbox) for training sample data. The lean Demo workspace (demo) used for public Sign up for a free demo is created manually on the marketing demo host — it is not seeded by the dacpac and must never be removed by a republish. That CTA (when enabled under Public site branding) targets Web:PublicSite:DemoTenantSlug (default demo) with self-registration on; keep SandBox self-reg off. Paid customer databases should not include a demo tenant.

To offer public signup on the marketing host: keep that demo workspace, enable self-registration on its detail page, and leave Show Sign up for a free demo button checked. To hide the button on a paid customer site, uncheck that option even if SandBox still exists for training.

Customer workspaces are created via New tenant workspace or the first-time setup wizard. Production data should live in a dedicated workspace with real users and integrations — not in SandBox.

Self-registration (per workspace)

On a workspace detail page, TenantAdmins can enable self-registration for that slug only. When on, the page shows a Request access link you can copy to prospects or staff. Registrants submit name and email; you approve or deny in the registration queue before they can sign in.

Any workspace can use self-registration — not only SandBox. Turn it on only for workspaces you trust on a shared host (SandBox for public trials; a private pilot slug for a known customer). Marketing Sign up for a free demo targets the configured demo slug; the link only works while self-registration is enabled on that workspace and the public-site button toggle is on.

Tenant workspaces vs User manager

Tenant workspaces shows the list of workspaces and, on detail, users for that chosen workspace. User manager always shows users in the workspace you are currently signed into. If you administer multiple workspaces, switch context in the header before opening User manager, or open users from the specific workspace detail page.

See also Multitenancy for isolation, security, and database scoping in more depth.

Admin → ADMIN → New tenant workspace (/admin/tenants/add) provisions another isolated workspace on the same install. Only TenantAdmin users see this link. Use it when onboarding a new customer, spinning up a training environment, or separating subsidiaries that must not share data.

Creating a workspace typically involves choosing a slug (short URL-safe identifier used in workspace switcher and sometimes URLs), a display name, and initial settings. The new workspace starts with default roles, empty operational data, and module defaults — you then enable applications, invite users, and configure integrations the same way you would for your first workspace.

Provisioning is intentionally separate from CRM Accounts. A CRM account is a customer your business sells to inside a workspace. A tenant workspace is the business environment itself. Confusing the two is a common onboarding mistake: "Add account" in CRM does not create a new workspace.

After you create a workspace

1. Switch into the new workspace with the header workspace switcher.
2. Open Integrations → Applications and enable the modules this customer purchased.
3. Invite users via User manager or enable self-registration on the workspace detail page.
4. Complete My organization letterhead for POs and invoices.
5. Connect QuickBooks, Stripe, and SMTP as needed.

Admin → Organization → My organization (/admin/my-organization) stores your company's legal letterhead — the name, logo, address, phone, tax ID, and related fields printed on operational documents. This is TenantAdmin configuration for the workspace you are in.

Letterhead is not the same as Public site branding. Letterhead appears on PDFs and printouts your business sends in the course of operations: purchase orders to vendors, sales order confirmations, invoices, packing slips, and similar SCM paperwork. Public site branding controls what anonymous visitors see on the marketing home page and blog. Many companies use the same logo in both places, but the data is stored separately so marketing can change a hero image without breaking PO layouts.

When you fulfill orders or email invoices, the system pulls organization fields into templates. Incomplete letterhead produces incomplete documents — set this up before go-live even if the public marketing site is not finished.

What to configure

• Legal name — as it should appear on contracts and tax documents.
• Logo — displayed on document headers; use a high-contrast image readable when printed.
• Address and phone — remit-to and contact blocks for vendors and customers.
• Tax identifiers — where applicable for invoices and compliance.

The page includes a letterhead preview so you can see approximate layout before printing a real PO. Changes apply to new documents; already-issued PDFs are not retroactively regenerated.

Admin → Organization → Integrations (/admin/integrations) is where the workspace meets the outside world: which apps are turned on, payment and accounting providers, outbound email, AI, analytics database access, and sync health. Only TenantAdmin should routinely change these settings. API keys and secrets are stored encrypted; after save they are not shown again — keep a secure record when rotating keys.

Applications tab

Choose which hub modules appear in the sidenav and HUB megamenu. Disabling an application hides navigation entry points and causes direct URLs to return 404 for users who are not administrators. Admin itself and public site settings remain available regardless. Enabling Inventory typically implies warehouse and order flows; Products alone is a lighter catalog tier for storefront SKUs without full SCM.

Providers tab

Connect external services by category:

• Accounting — QuickBooks Online OAuth (connect the company / realm). Products, vendors, customers, invoices, vendor bills, and payments can sync; use Sync status afterward.
• Payments — your Stripe for invoices / SO / store. See Stripe payments §1. Webhook: checkout.session.completed (+ invoice payment events). Platform paywall is §2 (ops only). Stack Stripe__* still required until BYOK ships.
• Shipping & maps / AI — carrier and map tokens; assistant BYOK keys (enable the assistant on the AI tab).

Each dedicated install uses that customer’s own Stripe and QuickBooks accounts — not Hivoltech platform SaaS keys.

Sync status tab

When QuickBooks is connected, Sync status summarizes Site_ExternalSync rows: counts synced, pending, and errored by record type (Product, Vendor, Customer, Invoice, VendorBill, Journal, and others). Recent errors list with one-click Re-sync. A red badge on the tab highlights outstanding failures. Use this page after posting journals or issuing invoices to confirm QBO received them.

Email (SMTP) tab

Override system email with tenant-specific SMTP — host, port, TLS, credentials, from/reply addresses. When custom SMTP is off, the host uses application-wide Smtp settings from server configuration. Tenant SMTP is used for notifications, invoice emails, and other outbound mail initiated inside the workspace.

AI assistant tab

Configure the workspace assistant: built-in model endpoint or bring your own key (BYOK), optional read-only SQL access for MODULE SCOPED DATA, and toggles for which modules the assistant may query. Without read-only data enabled, the assistant answers from general knowledge and your prompt only — not live inventory or pipeline numbers.

Read-only database tab

Provision a per-tenant SQL login for Power BI, Excel, Tableau, or SSMS reporting. Row-level security limits results to the workspace TenantId. This is reporting access, not a backup or migration path — operational changes still happen inside the app.

Operational letterhead is under My organization; marketing site appearance is under Public site branding.

Multitenancy is how one inveazy installation serves many separate organizations without mixing their data. If you are new to SaaS or hosted business software, think of each tenant (workspace) as its own company environment: own users, own products, own invoices — sitting on shared application code and database server infrastructure.

Every operational row in the database carries a TenantId (or equivalent scope) so queries always filter to the workspace you signed into. Users can belong to more than one workspace, but they work in one at a time via the workspace switcher in the header. Switching workspace changes every list, document, and dashboard you see.

Tenant vs workspace vs CRM account

Tenant and workspace mean the same thing in the UI. A CRM account is a customer company you sell to inside a workspace — not another tenant. A CRM organization is often a legal entity in your directory (vendor, partner, or customer). Do not confuse provisioning a new tenant with adding a CRM account.

Isolation and reporting

Application RBAC limits which modules a user sees within a tenant. Optional read-only database logins (Admin → Integrations) add SQL Server row-level security so BI tools cannot read another tenant's rows even if someone misconfigures a connection. See Tenant workspaces for provisioning and Integrations for external connections per tenant.

The ADMIN button in the top navigation bar is your control center for the whole inveazy installation and for the workspace you are signed into. It is aimed at people who configure the system — typically a TenantAdmin or Admin role — not at day-to-day warehouse or sales staff. If you do not see the ADMIN menu, your role does not include those permissions; ask your workspace administrator.

Unlike module menus (CRM, PM, SCM), the Admin menu is organized around how you run the workspace, not around a single business process. The ADMIN dropdown columns match the app:

• Dashboards — read-only analytics: overview launcher (/dashboard), CRM, project, financial, and SCM dashboards (sales, purchasing, inventory) when those modules are enabled. Documented in this Admin help group.
• Workspaces — tenant workspaces, users, and roles for the install you administer.
• Organization — My organization letterhead, Billing, and Integrations.
• Public site — opens Public site branding (documented in its own help sidebar group). TenantAdmin.
• Platform & help — provision/subscribers (ops hosts) and Help. See the Tenant Admin help group for platform-owner tasks.

Think of Admin as the layer above CRM, PM, and SCM for day-to-day workspace operations. Tenant Admin is the narrower platform-owner lane for provisioning tenants and wiring external services. Many small businesses have one person in both roles; larger deployments split them.

Who should use which Admin item?

A small business might have one TenantAdmin who does everything. A larger deployment often splits responsibilities:

• IT / platform owner — Tenant Admin topics: tenant workspaces, integrations, read-only database, SMTP, AI keys.
• HR or office manager — User manager, Roles, and My organization letterhead (TenantAdmin configures letterhead; Admin may request updates).
• Marketing — Public site branding help group (TenantAdmin).
• Executives — dashboards only, no configuration.

Work through dashboards in this group to orient yourself, then users and roles before inviting the team. Tenant provisioning and integrations live under Tenant Admin overview.

Documentation for Hub, CRM, PM, and SCM megamenus is in the sidebar groups below — each menu link has its own page.

Admin → Dashboards → Home opens the main app landing page at / when you are signed in. This is not the public marketing website visitors see before they log in; it is the hub launcher — a grid of tiles for every module your workspace has enabled (CRM, PM, Blog, Inventory, and so on).

After sign-in, most users start here to choose what to work on. The home page answers the question: What can I open in this workspace? Only modules turned on under Admin → Integrations → Applications appear as tiles. If Inventory is enabled, you will see SCM-related entry points; if only Products is enabled, you may see a lighter catalog-focused tile set.

The home launcher is intentionally simple. It does not show KPIs or alerts — those live on the Dashboard item in the same Admin column. Use Home when you want to jump into a module; use Dashboard when you want a quick health read across modules you have access to.

Relationship to the public site

Anonymous visitors hitting your organization's URL may see a marketing landing page instead of the sign-in screen, depending on Public site branding → Use landing page. Once authenticated, / is always the signed-in hub home, not the marketing layout. Keeping that distinction clear prevents confusion between brand/marketing settings and signed-in navigation.

Admin → Dashboards → Dashboard (/dashboard) is the dashboard launcher — a grid of cards that link to each analytics screen your role can access. Where the hub home (/) opens modules, this page answers: How is the business performing?

Cards appear based on enabled applications and permissions. Everyone with CRM may see the CRM dashboard card; Accounting unlocks the financial dashboard; Inventory unlocks purchasing, sales, and inventory dashboards. Open a card to drill into charts, KPIs, filters, exports, and optional Analyze buttons that send context to the Workspace assistant.

The same dashboards are listed under the Dashboards submenu in the left sidenav (and in the horizontal nav on smaller layouts). The ADMIN megamenu shows Home, Dashboard, CRM, and Project links in its first column; finance and SCM dashboards are on the launcher and sidenav even when they are not duplicated in that megamenu column.

All dashboard screens

Screen	Route	Requires
CRM dashboard	/dashboard/crm	CRM
Project dashboard	/dashboard/projects	PM
Financial dashboard	/dashboard/finance	Accounting
Sales dashboard	/dashboard/scm-sales	Inventory
Purchasing dashboard	/dashboard/scm-purchasing	Inventory
Inventory dashboard	/dashboard/scm-inventory	Inventory

When to use a module dashboard instead

If your question is specifically about sales pipeline health, open CRM dashboard. If it is about sprint load and project risk, open Project dashboard. For GL profit & loss and cash, use Financial dashboard. For open POs, booked sales, or stock on hand, use the three SCM dashboards. Operational SCM dashboards show document-level KPIs; the financial dashboard shows posted journal balances — both are useful and answer different questions.

Admin → Dashboards → CRM dashboard (/dashboard/crm) focuses on customer relationship metrics: pipeline value, stage distribution, activity trends, and related KPIs. This link appears only when the CRM module is enabled for the workspace.

CRM (Customer Relationship Management) is the part of the app where you track who you sell to and where deals stand before they become operational orders. Organizations and accounts represent companies; contacts are people; leads are early-stage prospects; opportunities are active deals with amounts and expected close dates. The CRM dashboard aggregates those records into charts and totals so managers can see funnel health without opening every opportunity.

The dashboard is read-only analytics. To change data — move a deal to another stage, log a call, convert a lead — use the CRM megamenu (Organizations, Pipeline, Opportunities, Activities). The dashboard tells you what shape the pipeline is in; the CRM menus are where work happens.

Typical workflow

A sales lead might check the CRM dashboard each morning for stalled opportunities and week-over-week trend arrows, then open CRM → Pipeline to drag cards across stages. Activities due today often surface through CRM list views or notifications rather than only through the dashboard.

Admin → Dashboards → Project dashboard (/dashboard/projects) summarizes project portfolio health: open work items, sprint progress, workload by assignee, and related KPIs. It appears when the Project Management (PM) module is enabled.

Project management in inveazy is for delivering work — internal initiatives, client projects, product development, or service engagements. A project groups work items (tasks, bugs, stories). Sprints time-box work; the Kanban board visualizes status columns; the Gantt chart shows schedules. The project dashboard rolls those details up for leads who need a portfolio view across many projects.

Like the CRM dashboard, this page is for monitoring. Updating assignments, moving cards on the board, or editing sprint dates happens under the PM megamenu (Projects hub, Tasks board, Sprints, Gantt).

CRM vs PM dashboards

CRM dashboards track revenue opportunities with customers. PM dashboards track execution of work your team agreed to deliver. A professional services firm might use both: CRM for signing the deal, PM for delivering the project. For a card-style portfolio snapshot without charts, PM → Overview (/pm/overview) is an alternative entry point.

Financial dashboard (/dashboard/finance) is the general ledger (GL) lens — profit & loss, cash flow, and account balances from posted journals. It unifies SCM-driven activity (invoices, bills, inventory movements) with manual Income & expenses cash entries. Open it from /dashboard, the sidenav Dashboards submenu, or the Accounting area when enabled.

This is read-only analytics. Posting and approving documents happens in SCM screens (sales orders, vendor bills, etc.) and cash-entry forms. QuickBooks sync is separate — see QuickBooks setup and Accounting overview for how local GL relates to exports.

Filters and period

Slice by organization, customer (account), project, and reporting period (year to date, last 12 months, this month, all time, or custom dates). KPI cards and charts refresh when you change filters. Use Export for PDF, Excel, or CSV snapshots of the current view.

Analyze with AI

The Analyze P&L button opens the Workspace assistant with financial context so you can ask for narrative summaries — still verify numbers against the on-screen KPIs before sharing externally.

SCM dashboards vs financial dashboard

SCM sales, purchasing, and inventory dashboards show operational documents (orders, POs, on-hand SKUs). Recognised revenue, AP expense, and inventory value on the books live here on the financial dashboard. Use both: SCM dashboards for fulfillment and spend velocity; financial dashboard for P&L and cash position.

Sales dashboard (/dashboard/scm-sales) is the operational sales view — booked order value, open backlog, fulfillment status, top customers and products, and regional breakdown when Mapbox is configured. Filter by customer, channel (desk sales vs storefront), and period. Requires the Inventory module (SCM sales documents).

Recognised revenue and accounts receivable on the GL appear on the Financial dashboard. This screen answers: What did we book? What is still open to ship? Who bought the most? Drill into Sales orders, Web orders, or Returns (RMA) to change data.

Typical KPIs

• Booked sales and order count for the selected period
• Open backlog value and lines awaiting fulfillment
• Order status mix (draft, confirmed, picking, shipped, etc.)
• Top customers and products; optional regional map
• Throughput — fill rate, pick-to-ship time, and order cycle time for the selected period

Export PDF/Excel/CSV or use Analyze to send the current filter context to the assistant. Pair with Purchasing dashboard when diagnosing supply constraints on hot sellers, and Inventory dashboard for pick-to-ship vs receiving pace.

Purchasing dashboard (/dashboard/scm-purchasing) tracks buy-side operations — vendor spend in the period, open purchase order commitment, open accounts payable, and spend by vendor. Filter by vendor and date range. Requires Inventory.

Vendor spend counts approved vendor bills in the period (not drafts or voids). Open PO value and open AP are point-in-time snapshots as of today, independent of the period filter. GL expense recognition is on the Financial dashboard; this page is for buyers and ops leads watching PO and bill pipeline.

Typical workflow

A purchasing manager reviews open PO and AP KPIs here, exports a vendor spend chart for a meeting, then opens Purchase orders or Vendor bills to approve or match receipts. Overdue PO lines that block sales often show up in both this dashboard and Backorders.

Inventory dashboard (/dashboard/scm-inventory) answers Is stock moving through the warehouse? — on-hand value and units, SKUs below reorder, expiring lots, slow/dead stock, cycle-count variance, recent movements, and low-stock alerts. Filter by warehouse and category. Requires Inventory.

Inventory value on the GL is on the Financial dashboard; this screen is operational. On-hand, expiry, and low-stock KPIs are point-in-time (as of today). Slow movers are stocked SKUs with no sale in a configurable window (default 180+ days) — consumables are excluded so gloves and supplies do not clutter the list. Cycle-count variance uses the current calendar quarter (QTR), not a rolling twelve months. A throughput section shows fill rate, pick-to-ship, and related warehouse velocity KPIs alongside the sales dashboard.

Where to act

• On-hand inventory — bin-level quantities
• Reorder alerts — SKUs below minimum, draft PO per vendor
• Cycle counts — post variances
• Backorders — demand waiting on stock
• Transfers — move stock between warehouses
• Mobile scanner — receive, pick, putaway, count on the floor

Use Analyze for assistant summaries; use Refresh after large receiving or adjustment sessions to update KPIs.

Admin → ADMIN → User manager (/admin/users) is the directory of people in the workspace you are signed into now. TenantAdmin and Admin roles can access it. From here you invite colleagues, assign roles, reset access, and open a user detail page for per-user settings.

Every person who signs in needs a user record tied to one or more workspaces. Roles (see Roles) decide which megamenus and modules appear. A warehouse clerk might have Inventory but not Admin; an AR clerk might have Accounting slices; a owner might be TenantAdmin with full configuration rights.

Adding users

Administrators can create users directly from User manager. Alternatively, self-registration lets people request access from a per-workspace link on Tenant workspaces → [workspace] → detail (Tenant workspaces). TenantAdmins enable the toggle, copy the Request access URL, and approve or deny pending requests before the person can sign in. Each workspace controls its own setting — useful for a public Demo trial (demo) or a private pilot slug. Direct invite from User manager is still faster for a handful of known emails.

Workspace context matters

User manager is always scoped to your current workspace. If you operate multiple tenants, switch workspace in the header before managing users, or manage them from Tenant workspaces → [workspace] → Users. The on-screen "How access works" callout on admin pages repeats this guidance for new TenantAdmins.

Users vs CRM contacts

Users can log in and have roles. CRM contacts are people you track for sales and support — they may never sign in. A customer's buyer might exist only as a CRM contact; your employee exists as a user. Linking the two is optional and separate from authentication.

Admin → ADMIN → Roles (/admin/roles) defines role-based access control (RBAC) for the current workspace. A role is a named bundle of permissions — which hub applications a user may open, and (for built-in admin roles) whether they can configure the workspace.

Built-in roles include TenantAdmin (full workspace configuration), Admin (user and role management without some tenant-provisioning actions), User (standard module access), and BlogEditor (content publishing). Built-in roles cannot be deleted; on most workspaces you can edit which applications they include. Custom roles can be added for job titles like "Warehouse", "AR Clerk", or "Sales Rep".

Applications vs roles

Integrations → Applications turns modules on for the whole workspace (CRM on/off, Inventory on/off). Roles decide which enabled modules a given user sees. If Inventory is enabled workspace-wide but a user's role excludes it, that user will not see SCM in the megamenu — even though the data exists for other roles.

This two-layer model lets you sell SCM to a company but restrict accounting exports to finance staff. Future work may split Accounting and Inventory into finer module codes; roles will follow the same pattern.

Practical guidance

• Give few people TenantAdmin; use Admin for day-to-day user management.
• Create custom roles that mirror real job functions instead of one "User" role for everyone.
• After changing role applications, ask affected users to refresh or sign out — megamenu visibility updates on next load.
• Disabled modules return 404 if someone bookmarks a URL — roles and application toggles both matter.

Admin → Public site → Public site branding (/admin/organization-site) controls the anonymous marketing experience — what people see at your organization's public URL before they sign in. TenantAdmin only. This is separate from signed-in hub chrome and separate from operational letterhead on POs/invoices.

Customer installs vs inveazy marketing

Paid customer sites should look like their company website, not an inveazy brochure. Uncheck the inveazy marketing toggles under General, then use Home hero, Landing blocks, Brand & PWA, and footer tabs for your own content. Hub apps stay available after sign-in; these settings only change what anonymous visitors see.

Topics in this group

• General — landing/blog/store toggles, company names, marketing switches
• Home hero — theme, hero image, headline, CTAs
• Landing blocks — rearrangeable HTML sections and starters
• Brand & PWA — logo, favicon, theme color, install metadata
• Contact — stock footer contact fields
• About & social — footer About copy and social links
• Custom footer — replace the stock footer with your HTML

Where branding is stored

Uploaded hero, logo, favicon, and PWA assets are saved in the database (Site_OrganizationSiteProfile for URLs and copy; Site_PublicSiteAsset for image bytes). The app also writes a cache copy under wwwroot/images/public-site/ and wwwroot/images/pwa/site/ on the server — those files are not in Git. When localhost and production share the same database, a branding change from either environment applies to both; each app server rebuilds its local cache from SQL on startup or first request.

Blog authoring for employees still happens under Hub → Blog; this screen only controls whether published posts are visible publicly and how the public site frame looks around them.

The General tab on /admin/organization-site turns public features on or off and sets display names.

Use landing page decides whether / for anonymous visitors shows a marketing home or redirects toward sign-in. Use blog controls only the stock “From the blog” cards at the bottom of the public home. Public /blog and the Blog navbar link stay available when Use blog is on or a landing blog-ticker block is enabled; both off hides the public blog. Signed-in users always get the hub launcher at / regardless of the landing toggle — the toggle affects guests only.

Show Sign up for a free demo button shows the public home CTA. Signups land in a trial workspace from Tenant workspaces: its Slug must match Web:PublicSite:DemoTenantSlug (default demo); Workspace name is display-only. On that workspace’s detail page, enable Enable self-registration for this workspace. Uncheck the button on paid customer sites. Do not point this at SandBox (sandbox).

Show services & capabilities on landing page and Show integrations strip on landing page are inveazy marketing sections (product/capabilities blocks, Hivoltech services, and the enterprise integrations logo strip). Leave them on for inveazy.com; uncheck both on customer installs so the public home does not advertise the platform.

Show Info button in public navbar is also an inveazy marketing / docs control — it shows the header Info link to public /help. Uncheck on customer installs. Signed-in users can still open Help from the hub / profile menu.

Show Pricing button and page controls the header Pricing link, home-page Features & pricing CTAs, and the public /pricing page (inveazy SaaS plans). Leave it on for the marketing/demo host; uncheck it on paid customer installs (host settings may hide this toggle entirely). On that page, a primary $ icon (not a green check) marks capacity notes: scale-up means enlarging one app or database; scale-out means adding instances. List price covers standard capacity — material scale may change managed Azure pricing; Self-hosted customers pay their own infra for those changes.

Use store turns on public /store and the header Shop link. Before taking card payments, configure commerce Stripe under Admin → Integrations → Providers → Payments (keys + webhook URL) — see Stripe payments. Catalog workspace comes from host Web:Store:CommerceTenantSlug.

Company display name is the public header/footer brand and the signed-in topbar label. Sidebar name is the left sidenav brand only — leave it blank to reuse the company display name, or set a shorter label when the full company name is too long for the menu.

Use custom landing page — when enabled, your hero copy and Landing blocks replace the stock inveazy pitch while shared theme controls still drive colors and header/footer chrome. With marketing sections off, the public home is essentially your hero + blocks + optional blog/footer.

Use footer shows a public footer. Use the stock four-column footer (Contact / About) or switch to your own HTML under Custom footer.

The Home hero tab sets the top marketing band: theme skin, color mode, navbar style, and hero imagery. Upload a hero image (JPEG, PNG, WebP, GIF, or SVG) or restore the default illustration (/images/center.jpg).

Use the Quill editor for the subhead (bold, lists, links, text size) — same idea as footer About. Set the primary button label/action (Contact modal, Sign in, or URL). When action is URL, the URL field appears beside Contact form destination email so inquiries go to your inbox (blank falls back to the server default).

Uncheck Show stock top hero when replacing the top hero with a Landing blocks starter such as Fullscreen image slider or Hero + slider. Settings on this tab still apply if you turn the stock hero back on later.

Use Preview home after saving to verify appearance on desktop and mobile.

The Landing blocks tab adds ordered HTML sections on the public home page below the hero (before integrations / capabilities / blog when those are on). Use a plain HTML textarea — not Quill — so you can paste HyperUI / Tailwind component markup without the editor rewriting it. Open the Theme & samples sub-tab for theme class chips and links to HyperUI, OpenTailwind, Preline, and Flowbite.

• Theme classes — prefer utilities such as text-default-900, bg-primary, and dark: variants so blocks match the site skin. Scripts and <style> / external stylesheets are stripped on save; SVG icons, images, Tailwind classes, and layout styles are kept.
• Order — use the up/down controls; that list order is the on-page order.
• Section id — becomes the HTML id on the section (anchor). Leave blank to auto-generate from the label.
• Show in public navbar — optional header button that scrolls to that section (#section-id). Optional navbar label defaults to the block label.
• Content width — Constrained, Wide, or Full (edge-to-edge for sliders).
• Insert starter — pick a template (apps sections, workflows, testimonials, FAQ accordion, timeline, blog ticker, logo cloud, gallery, and more), then Light or Dark and an optional soft Background tint. On image blocks use Pick image or Fill from folder (File Manager). Platform JS powers lightbox, filters, sliders, and scroll reveals — no pasted scripts. Edit HTML after insert. Use Block width (Constrained / Wide / Full) so content follows the navbar width — starters that use landing-block-shell respect that setting.

Max 20 blocks. Save, then Preview home. Disable a block without deleting it via the Enabled checkbox.

The Brand & PWA tab sets the public logo, favicon-related assets, theme color, and progressive-web-app metadata for add-to-home-screen experiences on mobile devices.

Assets are stored in SQL and cached under wwwroot/images/public-site/ and wwwroot/images/pwa/site/ (see Overview). After upload, hard-refresh the public site if a browser still shows an old favicon.

The Contact tab configures display contact email, phone, and address for the stock four-column footer (when Use footer is on and custom footer HTML is off).

The footer contact email is for display. The Home hero Contact form destination email is where Contact us form messages are sent — set that under Home hero.

The About & social tab sets rich About content for the stock footer and social network links (Facebook, Instagram, X, LinkedIn, YouTube, GitHub, and related).

These fields are ignored while Custom footer HTML is enabled — paste social links into your custom markup instead if you need them there.

Open Custom footer, enable Use custom footer HTML, and paste or insert your own footer markup (same HTML sanitizer as landing blocks). Insert starters support Light/Dark and soft Background tints like landing blocks.

The custom footer always renders at the bottom of the public home (after blog) and on blog/pricing/hub when the footer is enabled. Terms / Privacy / © remain underneath custom HTML.

While custom footer is on, the Contact and About tabs are ignored for the public chrome.

The HUB megamenu groups applications that support everyday collaboration — files, notifications, calendar, AI assistant, and blog — rather than a single business line like CRM or SCM. Open it from the top bar after sign-in. What you see depends on which hub modules are enabled under Admin → Integrations → Applications.

The dropdown has three columns:

• Hub apps — Hub overview (workspace landing), File Manager, Notifications (inbox and compose), Calendar.
• Assistant & Blog — Workspace assistant (AI chat) and Blog hub / All posts. About inveazy in the app menu opens the public feature catalog at /about.
• Next sessions — placeholders for future work (not documented as product features yet).

Open the sidebar Hub group for hub apps. AI documentation is in the Assistant group — start with Assistant overview.

The CRM megamenu is where you manage customers and sales pipeline before work becomes purchase orders or projects. CRM answers: Who are we selling to? What deals are open? What did we last discuss? It does not move physical inventory — that is SCM.

Columns in the CRM dropdown:

• ORG — Organizations (legal entities in your directory), Accounts (sell-to customers), Contacts (people), Leads (prospects).
• Pipeline — Pipeline board, Opportunities table, Activity board, Activities list.
• Dashboard & navigation — CRM dashboard, Deals overview, CRM Home hub page.

Open the sidebar CRM group for documentation on each screen — organizations, accounts, pipeline, opportunities, activities, and more.

The PM (Project Management) megamenu plans and tracks work delivery — internal projects, client engagements, or product development. It answers: What tasks are open? Who owns them? Are we on schedule?

Columns in the PM dropdown:

• Portfolio — Projects hub, Projects table, Work items table.
• Work & sprints — Sprints, Tasks board (Kanban), Gantt schedule.
• Dashboard — Project dashboard (portfolio KPIs).

PM links to CRM accounts and SCM projects where configured. Open the sidebar PM group for projects hub, work items, sprints, Kanban board, and Gantt.

The SCM megamenu — labeled SCM, Products, or Accounting depending on enabled modules — is the operational core for businesses that buy, stock, sell, and ship goods. Help topics are grouped in the sidebar as Buy side, Sell side, Accounting, and Storefront to match how teams think about the work.

Supply chain means the path from supplier to customer: you purchasing materials, receiving them into a warehouse, storing them in bins, picking them for orders, shipping to customers, and invoicing. inveazy records each step as a numbered document (PO-2026-0001, SO-2026-0042, etc.) so you can audit what happened and sync to QuickBooks.

Sidebar groups

• Buy side — master data (vendors, products, categories), purchase orders, receipts, and warehouse operations.
• Sell side — customers, quotes, sales orders, shipments, returns, backorders, and End-to-end workflows.
• Accounting — Accounting overview, QuickBooks setup, Stripe payments, Income & expenses, vendor bills, AP/AR exports, and customer invoices.
• Storefront — public B2B/B2C shop checkout and web-order fulfillment queue.

SCM dashboards

When Inventory is enabled, open analytics from /dashboard or the sidenav Dashboards submenu:

• Sales dashboard — booked orders, backlog, top customers/products
• Purchasing dashboard — vendor spend, open POs, open AP
• Inventory dashboard — on-hand, reorder, expiry, slow stock, variance (QTR), throughput
• Financial dashboard — P&L and GL balances (Accounting module)

Open the sidebar Buy side, Sell side, Accounting, and Storefront groups for every topic, or start with End-to-end workflows. Use Reference & glossary for PO, SO, FEFO, and accounting terms. Owned equipment such as toolboxes, machines, and vehicles lives under Assets Tracking — it is not inventoriable product stock.

Hub → Hub apps → Hub overview opens the workspace landing page at /apps/workspace. If you are new to inveazy, think of this screen as the front door to collaboration tools — files, messages, calendar, assistant, and blog — rather than the place where you run sales or warehouse operations. Those live under the CRM and SCM megamenus.

This page is different from the main Applications launcher at /hub (also reachable from Admin → Dashboards → Home). The /hub launcher shows tiles for every enabled module in your workspace — CRM, PM, Inventory, Blog, and so on. The workspace landing at /apps/workspace is narrower: it groups shortcuts to hub-style apps only, organized in cards so you can jump straight to All files, Notifications inbox, Calendar, Assistant, or Blog without hunting through the full module grid.

The layout uses three columns on wide screens. The first column covers File manager entry points (all files, recent, folders, and diagnostics for administrators). The second column covers Notifications (inbox and compose) plus Calendar. The third column shows Blog hub when that module is enabled; the Workspace assistant lives in its own top-bar column and in the Assistant group in this Help sidebar. Cards you do not see mean either the module is turned off under Integrations or your role does not include access.

When to start here vs the module launcher

Use /apps/workspace when your day revolves around documents, team messages, scheduling, or content — for example an office manager checking notifications, a marketer opening the blog, or anyone grabbing a file from a shared folder. Use /hub when you need CRM, PM, SCM, or another business module and want the full tile grid. Many users bookmark one or the other depending on their job; both are valid front doors after sign-in.

For the full Hub megamenu map, see Hub menu overview. Detailed guides for each card on this page are in the sidebar Hub group: File manager, Notifications inbox, Calendar, and Blog hub. AI chat is documented under Assistant — start with Assistant overview.

Hub → Hub apps → File Manager (/apps/file-manager) is where your workspace stores uploaded documents, images, and other attachments. If you have used Google Drive, Dropbox, or a network share, the idea is familiar: folders organize files, and each file has a name, size, and owner. inveazy keeps files inside your workspace so CRM, Blog, Notifications, and other modules can reference the same library without copying bytes into every feature.

The main view lists files and folders for the tenant you are signed into. You can browse the tree, open a folder to see its contents, upload new files, download or preview existing ones, and run actions the UI exposes (rename, move, delete — depending on your role). Recent (/apps/file-manager/recent) shows files you opened or changed lately, which is handy when you are jumping between blog images and email attachments. Folders (/apps/file-manager/folders) emphasizes the folder tree for quick navigation when you already know the directory structure.

Files uploaded here are not anonymous public links by default. Other signed-in users in the same workspace see them according to permissions. When you pick a featured image for a blog post or attach a file in Notifications compose, you are usually choosing from this library. The Workspace assistant (see Assistant in this sidebar) can also reference folder names when read-only data is enabled under Integrations → AI assistant.

Stock images and blog media

Marketing and blog workflows often rely on images stored in File manager. The Blog hub lets you attach featured images and inline media from your tenant library rather than pasting random URLs. Keep a sensible folder structure — for example Marketing / Blog / 2026 — so editors can find assets quickly. Large video files are supported in some editors, but email and notification delivery may still prefer smaller attachments; test before sending to external recipients.

Diagnostics (administrators)

TenantAdmin and Admin roles see a Diagnostics entry on the workspace landing and inside File manager (?view=diagnostics). This screen runs storage and pipeline health checks — useful when uploads fail or thumbnails do not generate. It is a troubleshooting tool, not a day-to-day browse view. Regular users should use All files or Recent instead.

File manager must be enabled under Admin → Integrations → Applications. If the menu link is missing, ask your administrator to enable it or grant your role access. See also Hub overview for shortcut cards into this app.

Hub → Hub apps → Notifications (/apps/notifications) is the in-app inbox for messages sent inside your workspace. It works like a simplified email client built into inveazy: you see a list of notifications, open one to read the full body, and optionally reply or follow links to related records (a purchase order, a CRM activity, a blog post). The bell icon in the top bar also surfaces recent items, but the inbox is where you search, filter, and work through everything systematically.

Notifications are tenant-scoped. You only see messages for the workspace you are signed into. System-generated alerts — for example when an order status changes or someone assigns you a task — may appear here alongside human-written broadcasts from Compose notification. Treat the inbox as the official record of what the app told you, even if you also received email for the same event (email depends on SMTP settings under Integrations).

The hub shell uses a left sidebar for navigation. In Mail mode you get folders, labels, and search across your tenant's notification stream. Click a row to expand the message; the layout can switch to a focused reading view with thread history and action buttons at the bottom. Unread items typically stand out in the list; use filters when the volume grows after go-live.

Folders, labels, and search

Folders help you organize messages the way you would in Outlook or Gmail — for example Operations, HR, or Archived. Labels add cross-cutting tags without moving the message out of its primary folder. Search scans subjects and bodies so you can find an old announcement months later. If you are unsure where a message lives, start with search rather than clicking every folder.

Bell dropdown vs full inbox

The topbar bell is a quick preview of the latest notifications. Use it for glanceable alerts during the day. When you need to mark items read in bulk, compose a reply, or read a long HTML message with images, open the full inbox. The bell's View all link lands on this same page.

To send a new message, use Compose notification. To see dates alongside CRM tasks and PM work items, switch the sidebar to Calendar mode or open Calendar directly. Notifications must be enabled under Integrations → Applications for non-admin users to reach this URL.

Hub → Hub apps → Compose (/apps/notifications/compose) is where you write a new notification to other users in the workspace — or, when configured, to external email addresses. Think of it as send a team announcement rather than edit a customer record. Sales updates still belong in CRM; warehouse alerts might be automated from SCM, but Compose is for deliberate human messages.

The compose screen uses a rich text editor (similar to the Blog hub) so you can format headings, bullet lists, links, and embedded images. Fill in recipients — often individual users, roles, or distribution lists depending on what your administrator enabled — plus a subject line and body. A Send action stores the notification in the tenant inbox and, when SMTP is configured, may also deliver HTML email to external inboxes. Plain-text fallback is used when HTML cannot be sent.

Before your first outbound message, confirm Admin → Integrations → Email (SMTP) is set up if you expect real email delivery. In-app delivery works without custom SMTP; email to external inboxes (Outlook, Gmail, etc.) does not. Tenant SMTP overrides the host-wide mail settings when turned on. See Integrations for host, port, TLS, and from-address fields.

Images and attachments

Inline images in compose are sanitized for safe storage and email rendering. Prefer images already uploaded to File manager when possible so you are not pasting untrusted URLs. Very large images may be slow for mobile readers; resize marketing graphics before embedding. Video embeds may appear in-app but not every email client displays them — include a text link as backup.

Who can compose?

Not every role can open Compose. Your workspace administrator controls access through roles and the Notifications module toggle. If you see the inbox but not Compose, ask for a role adjustment rather than sharing your account. Composed messages appear in recipients' Notifications inbox and may trigger bell alerts immediately after send.

After sending, return to the inbox to confirm delivery or open the message thread. For automated system notifications (order shipped, invoice paid), you do not use this screen — those originate from business modules and background jobs.

Hub → Hub apps → Calendar (/apps/calendar) shows upcoming dates in one grid-style view. The goal is to answer a simple question without opening three different modules: What is happening this week? Hub calendar events sit alongside dates pulled from CRM activities and PM work items when those modules are enabled, so sales follow-ups and project deadlines can appear next to team meetings or internal reminders.

You can open Calendar from the Hub megamenu, from the workspace landing cards, or by switching the Notifications hub sidebar to Calendar mode (the Mail | Calendar toggle at the bottom of the left panel on /apps/notifications). All routes aim at the same calendar experience; pick whichever entry point matches where you already are in the app.

Calendar is a read-oriented aggregation for most users today. Creating or editing the underlying CRM activity or PM task still happens in CRM or PM screens. When you click an item, the app should take you to the source record or show enough context to decide your next step. Do not expect full project scheduling (Gantt-level detail) here — that remains under PM → Gantt.

What appears on the grid?

Typical rows include CRM activities with due dates, PM work items with target dates, and hub-native calendar placeholders as the feature matures. Color or icon cues may distinguish module sources. If a module is disabled under Integrations, its dates will not feed the calendar. Empty grids usually mean no dated items exist yet, not a broken integration.

Planning your day

A practical morning routine: open Calendar for the week view, note overdue CRM activities, check PM items due before Friday, then jump into the relevant module to do the work. Pair this with the Notifications inbox for messages that do not have a calendar date attached.

Calendar access requires the Calendar application to be enabled and your role to include hub permissions. Administrators configure modules under Integrations → Applications.

Hub → Blog → Blog hub (/apps/blog) is the editor workspace for marketing and editorial content inside your tenant. If you have used WordPress or Medium's admin screens, the split is similar: this hub is where authors write and publish; the All posts library is where readers browse finished articles. Blog is optional — enable it under Integrations → Applications and grant blog edit permissions to marketing roles.

The hub uses a three-column shell. A post list or tree on the left helps you switch between drafts and published articles. The center holds the rich text composer (Quill) for title, body, and HTML source editing. The right rail stores metadata: slug, publish state, categories, tags, featured image from File manager, SEO fields, and landing-page options tied to Public site branding. Save often; long drafts are easier to recover than retyped paragraphs.

Publishing makes a post visible to readers who can open /apps/blog/read or follow links from your public marketing site when blog integration is wired. Draft posts stay inside the hub until you explicitly publish. Preview flows let you check layout before go-live. Exact public routing (subdomain vs path) depends on branding settings and roadmap items noted in the Hub megamenu's Next sessions column.

Compose, tags, and media

Write in the rich text editor for everyday formatting — headings, lists, bold, links, block quotes. Switch to HTML source when you need precise control or paste content from the Workspace assistant (blog scope outputs Quill-friendly HTML, not Markdown). Tags and categories help organize posts for the read index filters. Featured images should be chosen from File manager so URLs stay tenant-stable.

AI-assisted drafting

The hub links to /apps/assistant?scope=blog for review and rewrite workflows. Ask the assistant to critique structure, suggest SEO improvements, or produce a draft from a topic outline — then paste the HTML back into the composer. Scoped blog data lets the assistant see existing post titles and bodies when read-only data is enabled. See Workspace assistant for BYOK, models, and report formatting rules.

Who can edit?

Only roles with blog edit permission see the Blog hub link. Readers without edit rights may still open All posts when the Blog module is enabled. Coordinate with your TenantAdmin if marketing staff need compose access but should not see SCM or CRM menus — roles are granular under Roles.

After publishing, share the read URL with stakeholders or embed links in Compose notification announcements. Future roadmap items (public area routing, RSS feeds) are placeholders in the Hub menu and are not production features yet.

Hub → Blog → All posts (/apps/blog/read) is the read-friendly index of published blog content in your workspace. Authors live in Blog hub; this page is for browsing, searching, and opening individual articles without the editing chrome. Think of it as the internal newspaper rack for your company blog.

The layout typically includes a hero area for featured stories, a searchable grid or list of posts, and sidebar widgets for categories, latest posts, and popular tags. Click a title to open the full article at /apps/blog/post/{id}. The read view focuses on typography and images — not on Quill toolbars or publish buttons.

Filtering by category or tag helps new employees find onboarding articles or product release notes. Search matches titles and excerpts so you can jump directly to a policy document or tutorial. If a post does not appear, confirm it was published in the Blog hub and that your role may view blog content (the module can be enabled for readers who cannot edit).

Readers vs editors

Users with edit permission see shortcuts back to the hub to revise a post. Pure readers stay in the library and post detail pages. This separation mirrors how many organizations give all staff read access to the internal blog but limit compose rights to marketing.

Public site relationship

Depending on Public site branding, some posts may also surface on the anonymous marketing site visitors see before sign-in. The internal read index is always available to authenticated workspace users when Blog is enabled. Public routing features on the roadmap will extend discovery (RSS, dedicated public zones) without replacing this signed-in library.

Enable Blog under Integrations → Applications. For writing workflows, pair this page with Blog hub and optional Workspace assistant drafting at ?scope=blog (documented under Assistant in this sidebar).

CRM → ORG → Organizations (/crm/organizations) is your directory of companies and legal entities — customers, partners, vendors, or prospects you track in sales. If you are new to CRM software, think of an organization as the company name on the business card, not the individual person holding it.

Organizations sit at the top of the CRM hierarchy. Under each organization you can link accounts (sell-to customer records), contacts (people who work there), leads, and opportunities (active deals). Opening an organization detail page shows related records in one place so a rep can see everything tied to "Acme Manufacturing" without searching four different lists.

The list view is a searchable table. Use Add to create a new organization with fields like name, industry, and website. Click a row to open the detail profile — a read-first page with tabs for accounts, contacts, opportunities, and (where configured) linked PM projects. Edit uses the same modal pattern as other CRM lists: click Edit in list or return to the table and open the edit modal from there.

Organizations vs accounts

An organization is the legal or commercial entity. An account is often the customer relationship you sell through — sometimes one-to-one with an organization, sometimes more nuanced when one org has multiple bill-to or ship-to accounts. When in doubt, create the organization first, then add accounts linked to it from the account detail or organization profile.

Organizations vs tenant workspaces

Do not confuse CRM organizations with tenant workspaces under Admin. A workspace is your entire inveazy environment (users, modules, settings). A CRM organization is a company inside that workspace that you sell to or partner with. See Tenant workspaces if you are setting up the platform itself.

CRM → ORG → Accounts (/crm/accounts) lists your customer accounts — the sell-to relationships your sales team manages day to day. In many small businesses, "account" simply means "customer." Each account usually links to an organization and has contacts, opportunities, and activities attached.

Accounts are where pipeline work often starts: you pick the account when creating an opportunity, set a primary contact for quotes, and filter activities by account when preparing for a call. The table view supports search and filters so reps can quickly find "Midwest Distributors" or every account owned by a teammate.

Click an account to open its detail profile — summary fields, related contacts, open opportunities, and recent activity. Create and edit happen through modals on the list page (same pattern as organizations and leads), keeping the index page focused on scanning and filtering rather than long forms.

Accounts and SCM customers

When SCM (supply chain) is enabled, CRM accounts may link to operational customer records used on sales orders and invoices. CRM is where you nurture the relationship and track the deal; SCM is where you fulfill orders and ship goods. Sales might live entirely in CRM until a quote is won, then hand off to SCM for order entry.

Typical workflow

A common path for a new customer: create an organization, add an account linked to it, add contacts for buyers and approvers, convert or create an opportunity, then log activities (calls, meetings, follow-ups) until the deal closes.

CRM → ORG → Contacts (/crm/contacts) stores people — buyers, decision makers, technical contacts, and anyone you communicate with during the sales cycle. Contacts have names, email, phone, job title, and links to an account and/or organization.

Contacts are not the same as users who sign in to inveazy. A customer's purchasing manager might exist only as a CRM contact; your colleague exists as a user under Admin. Contacts never need passwords unless you separately invite them to a portal or storefront.

The contacts list uses a card layout on smaller screens and a table on desktop — optimized for recognizing people rather than comparing numeric columns. Search by name or email, filter by account or organization, and open a contact detail page to see related opportunities and activities. When you create an opportunity, you can set a primary contact so everyone knows who to call about that deal.

Why contacts matter

Deals are won by people, not company names alone. Logging who said what — and tying activities to the right contact — prevents the classic CRM failure mode where three reps call the same buyer because nobody updated the record. Assign an owner on the contact or account when your team grows beyond one salesperson.

CRM → ORG → Leads (/crm/leads) holds prospects — people or companies you have not yet qualified as real sales opportunities. Leads often come from trade shows, website forms, referrals, or cold outreach before you know budget, timeline, or fit.

Lead records include status (for example New, Contacted, Qualified, Disqualified), source, owner, and optional links to an organization or contact. The list supports search and status filters so inside sales can work a queue of fresh inquiries each morning.

When a lead is real — they have need, budget, and authority — you qualify it: create or link an account and contact, then open an opportunity on the pipeline. Until then, keep the record as a lead so your pipeline board stays focused on deals that count toward forecast, not every business card from last week's event.

Leads vs opportunities

A lead asks: Should we pursue this? An opportunity asks: How much might we win, and when? Opportunities have stages, amounts, and expected close dates used on the pipeline Kanban and CRM dashboard. Do not skip leads entirely if your process needs a qualification step — but do not clutter the pipeline with unqualified names either.

CRM → Pipeline → Pipeline (/crm/pipeline) is a Kanban board for opportunities — your visual sales funnel. Each column is a stage (such as Qualification, Proposal, Negotiation, Closed Won). Each card is one deal you can drag between stages as it progresses.

Kanban is a simple idea from manufacturing: work flows left to right (or top to bottom) through defined steps. In sales, the pipeline board answers Where is every deal stuck? at a glance. Managers scan column totals; reps drag cards after customer meetings instead of opening spreadsheets.

The board supports search and account filters so you can focus on one customer or rep. Click a card to open the opportunity detail page for amount, close date, line items, and related activities. Use New opportunity on the board header to create a deal without leaving the visual view. Switch to Table view (Opportunities) when you need sortable columns, bulk scanning, or export-friendly layouts.

Stages and forecasting

Stages are configured for your workspace (often by an admin). Early stages represent exploratory work; later stages mean a proposal is out or legal is reviewing. Expected close date and amount on each opportunity feed the CRM dashboard (/dashboard/crm) for funnel value and stage distribution charts.

Pipeline vs activity board

The Pipeline board tracks deals by sales stage. The Activity board (Activity board) tracks tasks and touchpoints (calls, meetings, to-dos) by activity type. Use both: pipeline for revenue motion, activity board for daily execution.

CRM → Pipeline → Opportunities (/crm/opportunities) is the table list of active deals — the same opportunity records shown as cards on the Pipeline Kanban, presented for sorting, filtering, and fast lookup.

An opportunity ties together an account (and often a primary contact), a stage, an estimated amount, probability or status, and an expected close date. Detail pages show line items when you quote products, related activities, and links back to the account and contact profiles. Edit opens from the list via modal, matching other CRM master lists.

Use the opportunities table when you need to answer questions like: Which deals close this month? Everything over $50k in Proposal stage? All opportunities for organization X? Use the pipeline board when you want to move deals visually during a pipeline review meeting.

When a deal closes

Moving an opportunity to Closed Won marks sales success in CRM. Fulfillment — purchase orders, projects, invoices — typically continues in SCM or PM depending on what you sold (physical goods vs a services engagement). CRM remains the historical record of how the customer relationship started.

CRM → Pipeline → Activity board (/crm/activities/board) is a Kanban view for activities — calls, emails, meetings, tasks, and other follow-ups — grouped by activity type rather than by sales stage.

Sales work is two rhythms: moving deals forward (pipeline) and doing the daily follow-ups that make deals move (activities). The activity board helps reps see "all my calls due today" or "meetings waiting to be scheduled" in columns, similar to how the pipeline board shows deals by stage.

Activities can link to an account, contact, lead, or opportunity so context travels with the task. Drag cards between columns when status changes (for example from Planned to Completed). Deep links from opportunity detail pages can open the board filtered to that deal's open activities.

Activity board vs activities list

The Activities list (/crm/activities) is a flat, filterable table — better for searching subject lines, due dates, or owners across hundreds of rows. The activity board is better for doing today's work in a visual queue. Many teams start the day on the board and switch to the list for reporting.

CRM → Pipeline → Activities (/crm/activities) is the master list of tasks and touchpoints — every logged call, meeting, email reminder, or to-do tied to your sales records.

Activities are the memory of your customer relationships. Without them, CRM devolves into a phone book with dollar amounts. With them, any rep can see that someone called last Tuesday, a demo is scheduled Friday, and a proposal follow-up is overdue. Each activity has subject, type, status, due date, owner, and optional links to account, contact, lead, or opportunity.

The list supports pagination, search, and filters (status, type, related records). Create new activities from the list or from opportunity and account detail pages so logging happens in context. Completed activities stay in history — they are not deleted — so handoffs between reps stay auditable.

Building a daily habit

A lightweight CRM discipline that works for small teams: end every customer interaction by creating or completing an activity; start each morning by filtering activities due today. Pair this list with the Activity board when you prefer columns over rows.

CRM → Dashboard & navigation → Deals (/crm/organizations/overview) is an organization-centered deal view — a card grid of companies with shortcuts into their accounts, contacts, opportunities, and pipeline work.

Where the pipeline board organizes by stage and the opportunities table organizes by deal rows, Deals organizes by customer company. It answers: For each organization we sell to, what is happening right now? Each card surfaces key metadata and links so you can jump into the right list without starting from global search.

This view suits account managers and owners who think in terms of named customers ("everything about Contoso") rather than individual opportunity IDs. Search filters the card grid by name, industry, or website. From a card you can drill into organization detail, open related opportunities, or switch to the organizations table for bulk admin work.

Deals vs pipeline

Use Pipeline for stage-based funnel reviews and drag-and-drop progression. Use Deals when your mental model is the customer portfolio — especially when one organization has multiple concurrent opportunities or cross-sell threads.

CRM → Dashboard & navigation → CRM Home (/crm) is the CRM navigation hub — a landing page that mirrors the CRM megamenu in three columns: ORG, Pipeline, and Dashboard & navigation.

If you are new to inveazy CRM, start here after sign-in. Each tile explains a module in one sentence and links to the live screen. You do not manage data on the home page itself; it orients you the same way the top bar dropdown does, but with room for short descriptions and counts when the overview API loads summary numbers.

Experienced users often bookmark deeper pages (/crm/pipeline, /crm/contacts) and skip home. New users and occasional CRM visitors benefit from the hub when they forget whether "Deals" or "Pipeline" is the Kanban view. For analytics, use CRM dashboard (/dashboard/crm) linked from the third column — charts and KPIs, not navigation tiles.

Suggested learning path

1. Read CRM menu overview for the big picture.
2. Set up Organizations and Accounts for your top customers.
3. Add Contacts and capture inbound names as Leads.
4. Create opportunities and work them on the Pipeline; log follow-ups in Activities.

PM → Portfolio → Projects hub (/pm) is the PM home page — a launcher with tiles for every major project-management screen in inveazy. If you have never used project software before, start here to see how the pieces fit together before diving into a specific list or board.

Project management (PM) is about delivering agreed work on time — internal initiatives, client implementations, product releases, or service engagements. Unlike CRM (which tracks who might buy), PM tracks what your team must build or deliver after the sale or alongside operations. The hub does not hold task data; it routes you to overview KPIs, project tables, work items, sprints, the Kanban board, and the Gantt chart.

The card order matches the PM megamenu: portfolio screens first, then execution tools (work items, sprints, board, schedule). Bookmark /pm if you split time between modules and want a neutral re-entry point into PM.

PM vs CRM

CRM opportunities represent revenue potential; PM projects represent delivery commitments. A consulting firm might win a deal in CRM, then create a PM project linked to the customer organization to track milestones and hours. Manufacturing might use PM lightly for plant improvement while SCM handles inventory. See CRM menu overview for the sales side.

PM → Portfolio → Projects (/pm/projects) is the master table of projects in your workspace. A project is a container — a named body of work with a code, status, owner, start and end dates, and optional links to a CRM organization or account when the engagement is customer-facing.

Think of a project as a folder that holds hundreds of work items (tasks, bugs, stories, chores). Examples: "Website redesign Q3," "Acme ERP rollout," or "Warehouse WMS phase 2." Without projects, work items would be an undifferentiated pile; with them, teams filter noise and report progress per initiative.

The table supports search and status filters. Click a row to drill into that project's work items or open project context on other PM screens. Create projects from the list when a new engagement starts; archive or complete them when delivery ends so dashboards stay honest about active load.

Projects vs work items

Projects answer What initiative is this part of? Work items (Work items) answer What specific task must someone do? You almost always pick a project before creating or filtering work items, sprints, or board columns.

PM → Portfolio → Work items (/pm/work-items) is the table view of tasks — the atomic units of project work. Each work item has a title, type, status, priority, assignee, sprint (optional), and parent project.

If you are new to PM tools, "work item" is a neutral term for anything trackable: a developer's bug fix, a consultant's deliverable, a marketing asset, or a facilities ticket. Items move through statuses (To Do, In Progress, Done, and your workspace's custom values) either on this table or on the Tasks board.

Select a project (and optionally a sprint) at the top of the page to scope the grid. Click a row to open the detail screen for description, comments, dates, and links. Use the table when you need sortable columns, bulk scanning, or to find one item by keyword across a large backlog.

Backlog vs sprint items

Items not yet assigned to a sprint live in the backlog — a holding area for future work. During sprint planning, teams pull items from the backlog into the active sprint. The same work item record travels; only the sprint field changes. See Sprints for time-boxing.

PM → Work & sprints → Sprints (/pm/sprints) lists sprints — fixed time boxes (often one or two weeks) during which the team commits to completing a set of work items. Sprints come from agile software development but work for any team that plans in short cycles.

Each sprint row shows name, date range, project, and counts of items (open, completed, total). Sprints give rhythm: plan on Monday, demo on Friday, retrospect what blocked you. Without sprints, backlogs grow forever; with them, you force prioritization conversations.

From the sprint table you can jump to the Tasks board or Work items filtered to that sprint. Creating a sprint is usually a lead or scrum-master action at the start of a cycle; individual contributors then pick up assigned items during the sprint.

Do you need sprints?

Small teams doing ad-hoc tasks can leave everything in the backlog and use the Kanban board without formal sprints. Sprints help when capacity planning, stakeholder demos, or velocity metrics matter. inveazy supports both modes — choose what matches your culture.

PM → Work & sprints → Tasks board (/pm/board) is a Kanban board for work items — columns represent status (To Do, In Progress, Review, Done), and cards represent individual tasks you drag as work advances.

Kanban visualizes flow: work enters on the left, exits on the right when complete. Stand-up meetings often happen in front of this board — each person moves their cards and calls out blockers. It is the execution counterpart to the Work items table, which is better for search and sorting.

On page load, pick a project and optionally a sprint — the board is always scoped so you are not mixing unrelated initiatives. Cards show assignee, priority, and title; click through for full detail. Drag-and-drop updates status immediately for the team.

Tasks board vs CRM pipeline

Both use Kanban columns, but they track different objects. CRM Pipeline moves sales opportunities by deal stage. PM Tasks board moves delivery work items by task status. Sales and delivery teams can each have a board without sharing columns.

PM → Work & sprints → Gantt (/pm/gantt) shows a schedule chart for one project — work items plotted on a timeline with start dates, end dates, and dependencies where configured.

Gantt charts answer When does each piece happen, and what blocks what? They suit waterfall-style planning, client milestones, or any project where executives expect a calendar view rather than a Kanban column. A long implementation might show design finishing before development starts, with testing trailing construction.

Select the project at the top of the page. Bars represent work items; dragging or editing dates updates the schedule (subject to your permissions). Use Gantt for stakeholder communication and deadline risk; use the Tasks board for daily team execution. Many teams live on the board during the week and review Gantt in monthly status meetings.

Keeping the schedule honest

Schedules drift when dates are set once and never updated. Treat Gantt as a living document: when a task slips on the board, adjust its dates here so portfolio dashboards and the Project dashboard (/dashboard/projects) reflect reality.

Suggested PM workflow

1. Create a Project for the initiative.
2. Break work into Work items; optionally group a cycle in a Sprint.
3. Execute daily on the Tasks board; communicate dates on Gantt.
4. Monitor portfolio health on the project dashboard and /pm/overview when you need KPIs across many projects.

SCM → Products & Vendors → Overview (/inventory) is the signed-in landing hub for supply chain work. If you are new to ERP (Enterprise Resource Planning) or WMS (Warehouse Management System) software, start here after reading the SCM menu overview. This page orients you to what your workspace can do — catalog only, full warehouse execution, or accounting — before you open purchase orders or pick lists.

The overview hub typically surfaces shortcuts into the megamenu columns you see in the top bar: master data (vendors, customers, products), operational documents (POs, SOs, receipts, shipments), warehouse screens (on-hand, transfers, cycle counts), and finance slices when Accounting is enabled. What appears depends on modules turned on under Admin → Integrations → Applications and on your role.

Think of SCM as the operational mirror of your physical business: you buy from suppliers, store goods, sell to customers, and record money owed and owed to you. CRM tracks the relationship before the deal closes; SCM tracks what happens after — stock moves, documents get numbered, and (optionally) journals post to your general ledger or QuickBooks.

Use this hub when you are not sure which SCM screen to open next. Purchasing staff often jump to Purchase orders or Receipts; warehouse staff to On-hand inventory, Reorder alerts, or Mobile scanner; finance to Invoices and Vendor bills. The Reference & glossary section defines acronyms used throughout SCM.

SCM → Products & Vendors → Vendors (/inventory/vendors) is your supplier directory — companies you buy from. A vendor record holds the name, remit-to address, default payment terms, tax identifiers, and contacts you need when raising a PO (purchase order) or recording an AP (accounts payable) bill.

In small businesses the vendor list might be dozens of rows; in distribution it can be hundreds. Each vendor is master data: it does not move inventory by itself. You reference a vendor on purchase orders, receipts, and vendor bills so spend rolls up correctly on the purchasing dashboard and in AP aging reports.

Set up vendors before your first PO. Capture lead times and preferred currency if you buy internationally. When Accounting is enabled, vendor terms (Net 30, Net 15, and so on) drive due dates on bills and help finance prioritize Vendor bills for payment. Linking a vendor to the right default expense or inventory accounts happens during integration setup — see Integrations for QuickBooks mapping.

Vendors are not CRM organizations, though the same real-world company might exist in both places: CRM for the relationship conversation, SCM for purchase documents. Keep vendor codes and names consistent so three-way match (PO, receipt, bill) is easy for your bookkeeper. See Purchase orders for the buy-side document flow.

SCM → Products & Vendors → Customers (/inventory/customers) lists sell-to accounts used on sales orders, quotes, shipments, and customer invoices. Where CRM tracks pipeline and contacts, SCM customers carry operational fields: ship-to and bill-to addresses, credit terms, tax exemption flags, and default price lists for SO (sales order) entry.

Every outbound document that represents revenue should point at a customer record so AR (accounts receivable) aging and regional sales dashboards stay accurate. Web storefront checkouts also resolve to SCM customers (or guest flows that create them) so web orders can fulfill like desk-entered orders.

Create customers before quotes or sales orders. If you already maintain CRM accounts, align names and links so sales does not duplicate "Acme Corp" three times. Credit limits and hold flags (when present) prevent shipping when a buyer is past due — finance and operations share the same customer truth.

Customer master data feeds Quotes, Sales orders, Shipments, and Invoices. Exported AR batches push invoice totals to QuickBooks when configured under Integrations. For the sell-side story end to end, read End-to-end workflows.

SCM → Products & Vendors → Products (/inventory/products) is your tenant SKU (Stock Keeping Unit) catalog — the items you buy, stock, and sell. Each product has a code, description, unit of measure, pricing, and (when Inventory is enabled) warehouse behavior such as lot tracking or default pick locations.

Products are the hinge between every SCM document. Purchase order lines, sales order lines, receipt lines, shipment lines, and invoice lines all reference the same SKU so quantities and costs stay consistent. A consumable is a product you use up rather than resell — shop supplies, packaging, or floor cleaner — often expensed on receipt instead of held as inventory; your bookkeeper sets that treatment per item or category.

The list view is a searchable grid for operators; add and edit open dedicated pages or modals when many fields are involved (dimensions, barcodes, images, vendor part cross-references). Enable Products alone for catalog and storefront pricing without warehouse screens; enable Inventory to track on-hand balances and run pick/pack workflows.

Organize products with Categories and optionally seed from the shared Product catalog. Before high-volume receiving, confirm each SKU has a unit of measure and (if you pick by location) a sensible default bin under Locations.

SCM → Products & Vendors → Product catalog (/inventory/products/catalog) exposes the platform master catalog — shared product definitions (often keyed by a master Inv#) that tenants can adopt instead of typing every field from scratch. If you have managed a distributor price book or industry data feed, the idea is similar: one canonical description, many workspaces copying what they sell.

Adoption copies master attributes into your tenant product list while keeping your local SKU codes, prices, and warehouse settings editable. This reduces onboarding time for new tenants and keeps naming consistent when multiple branches sell the same manufactured part.

Use the catalog when you are standing up a new workspace or expanding into a product line you do not yet maintain locally. After adoption, treat rows in Products as yours — adjust pricing, enable or disable storefront visibility, and assign categories. The catalog does not replace day-to-day edits on your live SKU list.

Catalog availability depends on host configuration and your Products module access. If you do not see expected master items, ask your TenantAdmin whether catalog sync is enabled. For terminology on SKU and consumables, see Reference & glossary and Products.

SCM → Products & Vendors → Categories (/inventory/categories) defines a hierarchical tree for grouping products — for example Hardware → Fasteners → Bolts. Categories help buyers browse the storefront, filter long product grids, and apply defaults (GL accounts, tax rules, or reporting buckets) consistently.

Unlike a flat tag list, parent/child categories preserve navigation breadcrumbs on the public store and in internal lists. Plan the tree early: reorganizing thousands of SKUs later is tedious. Many teams mirror their website navigation or their supplier's catalog structure.

Each product links to one primary category (and optionally secondary groupings depending on configuration). Purchasing reports and dashboards can slice spend by category when line items inherit the product's classification. Warehouse staff may still pick by SKU or bin regardless of category — categories are primarily a catalog and analytics tool.

Maintenance is an admin-style lookup table: search, add, edit, and drag to reparent nodes where the UI supports it. Pair category setup with Products import or Product catalog adoption so new items land in sensible branches from day one.

SCM → Purchasing & Sales → Purchase orders (/inventory/purchase-orders) is where you authorize spending with suppliers. A PO (purchase order) is a formal request: vendor, ship-to warehouse, line quantities, unit costs, and expected dates. It does not by itself increase on-hand stock — receiving does — but it commits your business to buy and gives the warehouse something to expect on the dock.

Typical statuses flow from draft → approved → partially received → closed. Buyers create POs from approved requisitions or ad hoc when stock is low. Link each line to a product SKU and quantity; optional project or department dimensions may exist for job-costing shops. Document numbers (PO-2026-0001) are audit-friendly handles referenced on receipts and vendor bills.

When goods arrive, warehouse staff post a Receipt against the PO so received quantities update on-hand balances and accrue inventory value for later three-way match (PO quantity/price, receipt quantity, vendor invoice amount). Short shipments leave PO lines open and may spawn Backorders on the buy side.

Open PO value appears on the SCM purchasing dashboard. Finance uses approved POs to control spend before AP posts. For the full buy-side chain PO → receive → bill → QuickBooks, see End-to-end workflows and Vendor bills.

SCM → Purchasing & Sales → Sales orders (/inventory/sales-orders) captures customer demand you intend to fulfill. An SO (sales order) lists ship-to customer, requested dates, line SKUs, quantities, and pricing — the operational counterpart to a CRM won deal or a accepted Quote.

Sales orders reserve or allocate inventory depending on configuration, drive pick lists, and feed shipment and invoice creation. Status columns tell warehouse and customer service where each order stands: open, picking, partially shipped, closed. Unlike a quote, an SO is a commitment to deliver and often triggers revenue recognition timing when invoiced.

Enter SOs from inside sales, customer service, or by converting quotes and web orders. Each line should reference a live product with sufficient on-hand or an explicit backorder path. Mobile scan workflows (where enabled) let pickers confirm quantities by barcode against SO lines.

After picking, create a Shipment to decrement stock and record carrier tracking, then an Invoice for AR. The sell-side narrative is spelled out in End-to-end workflows. Ensure Customers and Products exist before high-volume SO entry.

The Storefront is your workspace’s customer-facing shop — anonymous or signed-in buyers browse Products organized by Categories, add lines to a cart, and check out. Paid or approved orders land in Web orders for the same pick/ship/invoice pipeline as desk Sales orders, without a Quote step.

Storefront work spans three areas: catalog (what is visible and priced online — see Buy side product topics), checkout (Stripe payments under Accounting and public site branding under Public site branding), and fulfillment (web orders queue after payment). Operations staff should monitor on-hand in On-hand inventory so the store does not oversell.

Topics in this group

• Web orders — storefront checkout queue and fulfillment actions

Master data and warehouse execution live under Buy side and Sell side; finance topics (QuickBooks, Stripe, income & expenses) live under Accounting in the help sidebar. For the full quote-to-cash story including storefront, read End-to-end workflows.

SCM → Purchasing & Sales → Web orders (/inventory/web-orders) lists orders placed through your public storefront — the customer-facing shop tied to your workspace. Shoppers add SKUs to a cart, checkout with payment or account terms, and the order lands here for the same fulfillment pipeline as desk-entered sales orders.

Web orders bridge e-commerce and WMS execution. Operations staff review payment status, fraud holds, and ship-to addresses before releasing pick work. Many rows auto-map to underlying SO documents; others may stay in a web-specific status until a CSR confirms stock. Email notifications (order confirmation, shipment) depend on SMTP settings under Integrations.

Storefront visibility comes from product and category setup in Products plus public site branding in Admin. Inventory availability shown online should reflect On-hand inventory minus allocations so you do not oversell. Stripe for checkout is configured via stack Stripe__* and Integrations → Providers → Payments.

Treat web orders as the entry point for B2C or lightweight B2B self-service. Returns from the store flow into Returns (RMA). For quote-driven B2B sales that never touch the cart, use Quotes and Sales orders instead.

SCM → Purchasing & Sales → Quotes (/inventory/quotes) holds proposals — priced line items for a prospect or customer before anyone commits inventory or revenue. Quotes carry expiration dates, optional discounts, and ship-to hints so sales can iterate without creating a live SO.

In ERP language a quote is non-posting: it does not move stock or GL balances. When the buyer accepts, convert the quote to a SO in one action, carrying lines and pricing forward. That conversion is the handoff from sales negotiation to warehouse fulfillment documented in End-to-end workflows.

Quotes complement CRM opportunities: CRM may track stage and probability; SCM quotes hold SKU-level detail ready for pickers. Align customer records between CRM accounts and SCM customers so conversion does not require retyping addresses.

Print or email quote PDFs using letterhead from Admin → My organization. Revise quotes by versioning or editing draft rows depending on your process. Lost quotes simply expire; won quotes become sales orders and may spawn partial shipments over time.

SCM → Purchasing & Sales → Receipts (/inventory/receipts) records inbound goods — what actually arrived on the dock against a PO or ad hoc. Receiving is the moment on-hand inventory increases (for stock items) and accrued liability may start for later AP matching.

Warehouse staff verify vendor packing slips against PO lines, enter received quantities, and optionally capture lot numbers, serials, or expiration dates for FEFO (First Expire, First Out) picking — ship or consume the oldest expiry first to reduce waste. Putaway directs stock into a target warehouse and bin (Locations).

Partial receipts are normal: close PO lines only when fully received or explicitly cancelled. Over-receipts should be flagged before posting so three-way match stays clean when the vendor bill arrives. Mobile receiving (scan workflows) speeds high-volume SKUs when Inventory mobile is enabled.

Receipts tie forward to Vendor bills and backward to Purchase orders. Finance expects received quantity × PO cost to approximate the bill. See On-hand inventory for balances after posting and End-to-end workflows for the PO leg.

SCM → Purchasing & Sales → Shipments (/inventory/shipments) documents outbound fulfillment — cartons leaving the warehouse against a sales order or web order. A shipment records what was picked, packed, weighed, and handed to a carrier, with tracking numbers for customer service.

Operationally, shipment posting decrements on-hand at the source bin and marks SO lines shipped. Partial shipments are common in backorder situations: ship what you have today, leave remaining quantity open for a later shipment or Backorder release when stock arrives.

Pickers may use paper pick lists or mobile scan confirmation depending on your setup. Capture package count and freight method for rate shopping audits. Shipment documents are the proof operations needs when a customer asks "did you ship my order?" before AR sends the invoice.

Shipments sit between Sales orders and Invoices in the quote → SO → pick → ship → invoice chain (End-to-end workflows). Returns reverse portions of this flow through Returns (RMA).

SCM → Purchasing & Sales → Returns (RMA) (/inventory/returns) manages customer returns — goods coming back after a shipment or store purchase. An RMA (Return Merchandise Authorization) is the controlled authorization number and document that tells the warehouse what to expect and whether to restock, scrap, or credit the buyer.

Returns reverse pieces of the outbound flow: received return quantity may increase on-hand in a quarantine or resale bin, trigger a credit memo against AR, or route to vendor warranty for supplier RMA. Link returns to the original SO or web order when possible so quantities and pricing match what the customer actually received.

Customer service creates the RMA with reason codes (defective, wrong item, changed mind). Warehouse inspects upon receipt — not every unit returns to sellable stock. Finance coordinates refund timing with payment processor or credit on account.

Store-initiated returns from Web orders land in the same queue. For terminology on AR credits, see Invoices and Reference & glossary. Sell-side and return paths together are summarized in End-to-end workflows.

SCM → Warehouse operations → Warehouses (/inventory/warehouses) defines physical or logical stocking sites — main DC, retail back room, 3PL partner site. Every on-hand balance, receipt, shipment, and transfer is scoped to a warehouse so multi-site businesses do not commingle quantities.

Create at least one warehouse before receiving or transferring stock. Each warehouse has an address used on PO ship-to lines and may have default picking strategies. Users and roles can restrict which warehouses appear for a given clerk — a store associate might only see the retail warehouse, not the central DC.

Warehouses contain bins (Locations): aisles, shelves, staging lanes, and quarantine areas. WMS discipline means "no bin, no pick" — even a single-site shop benefits from a RECEIVING and SHIPPING staging bin to keep counts honest during busy days.

Warehouse master data underpins On-hand inventory, Transfers, and Cycle counts. Enable Inventory under Integrations before these screens appear in the megamenu.

SCM → Warehouse operations → Locations (/inventory/locations) lists bins, zones, and shelves inside a warehouse — the smallest address pickers use when they walk the floor. A bin code like A-03-02 (aisle-rack-level) tells staff exactly where a SKU lives.

Locations enable bin-level on-hand, directed putaway, and cycle counts by zone. Without bins, inventory may still exist at warehouse level only, but accuracy suffers as SKU count grows. Staging bins (RECV, PACK, SHIP) separate in-transit quantities from sellable shelf stock.

Define locations before high-volume receiving so putaway rules have targets. Some products require temperature-controlled or hazmat bins; note that in location descriptions for training. Barcode labels on bins pair with mobile scan pick and count apps.

On-hand balances by bin appear under On-hand inventory. Transfers may move stock bin-to-bin within a warehouse or warehouse-to-warehouse via Transfers. See Warehouses for site setup first.

SCM → Warehouse operations → Inventory (/inventory/on-hand) shows quantity on hand by product, warehouse, and (when tracked) bin. This is the operational truth pickers and buyers consult — not the same as CRM pipeline or PO open quantity, but the net physical (or system-tracked) stock available to promise.

On-hand changes when you post receipts, shipments, transfers, adjustments from cycle counts, and approved returns. Allocations against open SOs may reduce available quantity even while on-hand remains until shipment posts. Learn both columns if your grid exposes allocated vs free balance.

Lot and expiry tracking supports FEFO picking for perishables — the system suggests the bin with the soonest expiration. Non-stock consumables may never appear here if you expense them on receipt rather than carrying inventory.

Use this screen for daily stand-ups: what is out of stock, what is overstuffed, which bin to count next. Drill into transaction history from product detail when investigating discrepancies. Pair with Cycle counts to correct drift and Backorders when available quantity cannot cover SO lines.

SCM → Warehouse operations → Transfers (/inventory/transfers) moves stock between warehouses or bins without a customer sale or vendor purchase. Retail replenishment (DC to store), consolidating partial bins, or sending demo units to a trade-show warehouse are everyday transfer scenarios.

A transfer document lists source and destination, SKUs, and quantities. Posting decreases on-hand at the origin and increases at the destination in one coordinated transaction, preserving total enterprise quantity. In-transit status may apply when a truck is between sites overnight.

Transfers do not create revenue or AP by themselves — they are internal logistics. Mis-posted transfers are a common reason cycle counts disagree; always confirm bin barcodes when scanning. Large transfers may require approval roles similar to PO approval.

Setup requires at least two Warehouses or multiple Locations. Verify results on On-hand inventory after posting. For external inbound/outbound, use Receipts and Shipments instead.

SCM → Warehouse operations → Cycle counts (/inventory/cycle-counts) supports physical inventory counts on a rolling schedule — count aisle A this week, aisle B next — instead of shutting down the entire warehouse for an annual wall-to-wall count.

Supervisors create count batches by warehouse, zone, or product class. Counters enter scanned or keyed quantities per bin; the system compares to expected on-hand and highlights variance. Approved adjustments post inventory corrections and may feed GL adjustment entries when Accounting is enabled.

Good cycle count hygiene treats variance as a process signal: receiving errors, unposted shipments, theft, or unit-of-measure mistakes. Investigate large deltas before accepting adjustments. Freeze picking on a bin while counting if your process requires it.

Cycle counts complement — not replace — transaction discipline on Receipts, Shipments, and Transfers. See On-hand inventory for balances before and after reconciliation.

SCM → Warehouse operations → Backorders (/inventory/backorders) lists order lines that could not be fully picked because available stock was short — or, on the buy side, PO lines not yet received. Backorder queues help customer service set expectations and help buyers chase vendors.

When pickers short-ship an SO, remaining quantity often stays open as backordered until replenishment arrives. FIFO (first in, first out) or FEFO allocation rules determine which waiting orders get stock first when a receipt posts. The purchasing dashboard may highlight PO lines overdue to receive that block sales.

Proactive backorder management reduces cancel rates: notify customers of delays, swap equivalent SKUs when allowed, or partial ship with consent. Finance should know backordered revenue is not yet invoiced — AR follows shipment, not SO entry.

Clear backorders by receiving against Purchase orders, transferring from another Warehouse, or adjusting demand on the Sales order. See End-to-end workflows for how backorders sit in the fulfillment chain.

inveazy Accounting is the finance slice of SCM: you run warehouse and sales operations here, record money in and out, and optionally keep QuickBooks Online (QBO) aligned as your accountant’s system of record. inveazy is not a full QuickBooks replacement — it gives you operational AR/AP, a lightweight general ledger (GL) in SQL (Acct_Journal), and controlled export/sync to QBO. Stripe is the card-payment rail for customer invoices and storefront checkout; inveazy never stores card numbers.

Enable the Accounting module and connect providers under Admin → Integrations. Each workspace connects its own QBO company and Stripe account. After changes, use Sync status on that screen to confirm exports succeeded.

Three layers: operations, local GL, QuickBooks, Stripe

Think of four cooperating pieces:

1. SCM documents — purchase orders, receipts, shipments, vendor bills, and customer invoices. These mirror what happened in the warehouse and on the sales desk.
2. Local GL — balanced journal entries posted in inveazy when you approve documents or record payments. You can report in-app (finance dashboards, GL queries) without opening QuickBooks every day.
3. QuickBooks Online — optional but typical for small businesses. Master data (products, vendors, customers) and subledger documents (Bills, Invoices, Payments) sync or export to QBO. Your bookkeeper reconciles bank accounts and runs formal financial statements there.
4. Stripe — optional card collection. Customers pay on a Stripe-hosted checkout page; webhooks tell inveazy the invoice is paid. Processing fees are tracked for GL and can be reflected in QBO without double-counting revenue.

Sell side (simplified):
  Quote → Sales order → Shipment → Invoice
    │                              ├─ Local GL: DR Accounts Receivable / CR Revenue (+ tax)
    │                              ├─ QBO: Invoice (via AR export batch or direct sync)
    │                              └─ Customer pays → Stripe Checkout OR check/ACH recorded in-app
    │                                     ├─ Local GL: clear AR to Cash (fee split if Stripe)
    │                                     └─ QBO: Payment on Invoice (+ fee entry if Stripe)

Buy side (simplified):
  PO → Receipt → Vendor bill
    │       ├─ Local GL: inventory / GR-IR on receipt (when enabled)
    │       └─ QBO: Bill (via AP export batch or direct sync)
    └─ You pay vendor in bank / QBO Bill Pay (outside inveazy)

Outside PO/SO:
  Income & expenses (cash entry) → Local GL → QBO Purchase (expense) or Deposit (income)

Income & expenses (Acct_CashEntry)

Income & expenses (/inventory/cash-entries) is for money that does not belong on a formal vendor bill or customer invoice — petty cash, bank service charges, a one-off consulting deposit, or a quick office supply run without a PO. Each entry is either expense or income, with:

• A category account (expense or revenue line on your chart).
• A money account (bank or cash — e.g. operating checking).
• Amount, date, payee/party, memo, and optional link to a CRM customer on income rows.

Workflow: save as draft, then post. Posting creates a balanced local journal — expense posts DR category / CR money; income posts DR money / CR category. If QuickBooks is connected, the entry syncs as a native QBO Purchase (expense) or Deposit (income), not as a duplicate journal entry. Edits to a posted entry update both the local journal and the existing QBO transaction on re-sync.

Use Vendor bills and Invoices when you need open AP/AR aging, three-way match, or ties to PO/SO lines — not cash entries.

Accounts receivable — invoices, exports, and Stripe

When you issue a customer invoice from fulfilled sales (or a storefront order), inveazy records what the customer owes:

• Local GL at invoice — typically debits Accounts Receivable and credits sales revenue (and sales tax payable when applicable). Shipment posting may also move COGS and inventory when inventory accounting is enabled.
• QuickBooks — approved invoices export through AR export batches (or sync on demand). Customers, items, and tax accounts must map to QBO first — configure under Integrations.
• Stripe payment — when Stripe is enabled, sending an invoice email can create a Stripe Checkout link (checkout.stripe.com). The customer pays on Stripe’s page; a webhook marks the invoice paid in inveazy. Local GL then records cash received net of Stripe’s processing fee (fee booked to a merchant-fees expense account). QuickBooks receives a native Payment against the invoice for the gross amount, plus a separate fee entry — the app avoids pushing the full cash-receipt journal twice so QBO does not double-count AR.
• Non-Stripe payment — check, ACH, wire, or cash recorded manually clears AR in the local GL (DR bank / CR AR). QuickBooks payment recording for manual methods may be completed in QBO; the local books still reflect the receipt for in-app reporting.

Storefront Web orders follow the same pattern: order → shipment → invoice → Stripe checkout at checkout or invoice email, depending on terms.

Accounts payable — vendor bills and export batches

On the buy side, a vendor bill records what you owe after goods or services arrive. Match it to the PO and receipt when possible (three-way match). Approved bills roll into AP export batches and become QBO Bills. You pay suppliers in your bank portal or QuickBooks Bill Pay; inveazy tracks approval and open balance until export and payment are reflected in QBO.

Receipt posting may capitalize inventory or expense consumables immediately depending on product setup — see End-to-end workflows for the PO → receive → bill chain.

Avoiding double-counting in QuickBooks

inveazy deliberately separates native QBO documents from journal-only events:

Event in inveazy	Local GL	What goes to QuickBooks
Customer invoice	Yes — AR / revenue	QBO Invoice (not the same journal again)
Vendor bill	Yes — AP / expense or inventory	QBO Bill
Income / expense cash entry	Yes	QBO Purchase or Deposit
Stripe invoice payment	Yes — cash, fee, clear AR	QBO Payment + fee entry (not duplicate cash journal)
Cycle count variance, some adjustments	Yes	QBO Journal entry (no native document)

If Sync status shows errors, fix account or name mapping, then Re-sync. Common failures: missing QBO bank account for cash entries, customer not synced before an AR deposit, or item/account mismatch on bills.

Typical month-end rhythm

1. Close warehouse activity — finish shipments and receipts for the period.
2. Post stray cash items in Income & expenses.
3. Approve vendor bills and invoices; run AP and AR export batches to QuickBooks.
4. Confirm Stripe-paid invoices show paid and check Sync status for QBO payments and fees.
5. Reconcile bank and QBO in QuickBooks (official statements) — inveazy operational totals should align with exported documents.

Where to read next

• Income & expenses — day-to-day cash in/out outside PO/SO.
• Stripe payments — platform vs tenant commerce, checkout, webhooks.
• QuickBooks setup — OAuth checklist and troubleshooting.
• Invoices and AR export batches — money customers owe you.
• Vendor bills and AP export batches — money you owe suppliers.
• End-to-end workflows — sell-side and buy-side document chains.
• Integrations — Stripe, QuickBooks OAuth, sync status, module toggles.
• Reference & glossary — AR, AP, GL, COGS, export batch definitions.

There are two different Stripe setups. They use different Stripe accounts, keys, and webhook events. Do not mix them.

1. Your Stripe — invoices, sales orders, and store

Buyers pay your business. Use your Stripe account. Configure under Admin → Integrations → Providers → Payments (and the same keys under Admin → Integrations → Payments; host Stripe__* is a fallback). Never paste Hivoltech / inveazy platform keys here.

Setup

1. Enable Accounting (and Inventory / store if needed) under Integrations → Applications.
2. In your Stripe Account Dashboard → Developers → API keys, copy the secret and publishable keys.
3. In the app, open Integrations → Payments, paste the keys, enable Stripe, and Copy the webhook URL.
4. Create your webhook endpoint in your Stripe Account Dashboard → Developers → Webhooks → Add endpoint → paste that URL → select the events below → copy the signing secret (whsec_…) into Webhook signing secret (and stack Stripe__WebhookSecret). Success/cancel URLs are set by the app, not in Stripe.
5. Put the same secret, publishable, and webhook values on stack env and recreate the app container.
6. Test in Stripe test mode (invoice or store pay with 4242…), then switch to live when ready.

Webhook events (your commerce account)

• checkout.session.completed — required
• invoice.payment_succeeded — recommended
• invoice.payment_failed — recommended

Leave Connect webhook secret blank unless you use Stripe Connect.

How payment works

1. Finance sends a customer invoice, or the store / SO collects payment.
2. The buyer pays on Stripe Checkout (checkout.stripe.com). inveazy never stores card numbers.
3. checkout.session.completed marks the invoice or order paid and GL can post (see Accounting).

Web orders use the same commerce keys. Payment terms on Customers decide prepaid vs invoice later.

For in-person card readers on the till (Stripe Terminal S700/S710), see Counter POS → Stripe card readers. Same commerce keys; different Dashboard Location/reader registration.

2. inveazy platform — license / paywall

Hivoltech operators only. Tenants subscribe on https://inveazy.com/pricing. Keys live on the marketing Container App env (Stripe__*), not on a customer Integrations → Payments page. Customer TenantAdmins can skip this section.

Where configured

• Azure Container App for inveazy.com (and deploy/secrets/platform.env on the provision host for new customer billing sync).
• Webhook URL: https://inveazy.com/api/billing/stripe/webhook
• In-app subscription management on a paid site: Admin → Billing (after the paywall sub is linked).

Webhook events (inveazy.com endpoint only)

• checkout.session.completed
• customer.subscription.created
• customer.subscription.updated
• customer.subscription.deleted
• invoice.payment_succeeded
• invoice.payment_failed

Troubleshooting (section 1)

• Pay button missing — stack Stripe__SecretKey empty, Accounting off, or invoice not sendable.
• Paid in Stripe but invoice still open — wrong webhook URL, missing checkout.session.completed, or wrong whsec_.
• Keys saved in Integrations but pay fails — also set stack Stripe__* and recreate the container.
• Test vs live mismatch — keys and Dashboard mode must match.
• Localhost — use stripe listen --forward-to http://localhost:5148/api/billing/stripe/webhook; do not register localhost in the Dashboard.

QuickBooks Online (QBO) is the usual system of record for small-business books after operations run in inveazy. Connect once per workspace under Admin → Integrations → Providers → QuickBooks Online. OAuth tokens are stored encrypted; Intuit handles sign-in — you pick the QBO company (sandbox companies work for testing).

Read Accounting overview first for how local GL, export batches, and native QBO documents fit together without double-counting.

First-time checklist

1. Enable modules — Accounting (and Inventory if you sync products) on Integrations → Applications.
2. Seed chart of accounts — new tenants get a default chart via sp_Acct_SeedDefaultGlChart (accounts such as 1000 Cash, 1100 AR, 1200 Inventory, 2000 AP, 5000 COGS, 6400 Bank & Merchant Fees). Posting errors mentioning a missing GL account may require re-running seed for the tenant.
3. Connect QBO — Providers → QuickBooks → Connect to QuickBooks. Complete Intuit OAuth; confirm Sync status shows connected realm. If Connect fails with redirect_uri is invalid, email [email protected] with your site URL so we can register the callback on the Intuit app — customers do not configure redirect or webhook URLs.
4. Webhook (optional) — outbound sync works without it. Intuit → inveazy change notifications are registered by us when needed.
5. Sync master data (order matters for fewer errors):
   • Products → QBO Items
   • Vendors → QBO Vendors
   • Customers (CRM accounts) → QBO Customers
6. Smoke test transactional sync — post one cash entry (Purchase or Deposit), one vendor bill, one invoice. Use normal approval + AP/AR export batches depending on your workflow.
7. Review Sync status — confirm Product, Vendor, Customer, Invoice, VendorBill, CashEntry rows show synced; clear any errors with Re-sync.

What syncs as what

inveazy document	QuickBooks entity	Notes
Customer invoice	Invoice + Payment (when paid, incl. Stripe)	Do not also push the invoice GL journal
Vendor bill	Bill	AP export batch groups releases
Income / expense cash entry	Deposit (income) or Purchase (expense)	Money account must map to a QBO Bank account
Cycle count / some adjustments	Journal entry	No native QBO document in inveazy
Product	Item	Expense/income accounts resolved from GL mapping

Export batches vs direct sync

AR and AP export batches let finance review totals before releasing a group to QBO — typical for month-end. Individual documents may also sync on approval or via Re-sync from Sync status when a single row failed. Re-sync on an already-linked record updates the same QBO entity rather than creating duplicates.

Common errors and fixes

Symptom	Likely cause	Fix
Cash entry sync failed — bank account	Money GL account has no matching QBO Bank	Create/map bank account in QBO; re-sync entry
Invoice sync failed — customer	CRM account not synced to QBO Customer	Sync customer first; re-sync invoice
Bill sync failed — vendor or account	Vendor missing or expense account mismatch	Sync vendor; align bill line accounts with QBO chart
Product / item errors	No expense or income account in QBO for item type	Fix product GL mapping; sync product again
OAuth / token errors	Refresh token revoked or company disconnected	Reconnect QuickBooks on Providers tab
Stripe paid but QB payment missing	Invoice not in QBO yet or sync lag	Export/sync invoice first; check AR batch Re-sync for fee payment

After fixing mapping, use Sync status → Re-sync on the failed row. Persistent failures often mean the QBO company chart differs from inveazy defaults — align account names/numbers or adjust product and category GL links before bulk month-end exports.

Related: Integrations (OAuth UI), Stripe payments (invoice checkout), Reference & glossary (AR, AP, GL terms).

SCM → Accounting → Income & expenses (/inventory/cash-entries) records cash in and cash out that does not naturally flow through a sales order or purchase order — bank fees, petty cash, simple service income, or office supply runs paid on a corporate card without a formal PO.

These entries keep the operational books aligned with reality between formal AR/AP documents. Each row typically picks an account category, amount, date, and memo so exports or GL posting can map to the right chart-of-accounts line in QuickBooks or your general ledger. For how cash entries fit with invoices, Stripe, and QBO, read Accounting overview first.

Do not use cash entries as a shortcut for vendor bills or customer invoices when three-way match and open AP/AR aging are required — use Vendor bills and Invoices for trade payables and receivables tied to suppliers and customers.

CapEx: When you buy long-lived equipment, you can record the spend as an expense cash entry against a capital account such as 1500 Fixed Assets (shown as capital in the category list). Prefer an investing cash-flow class for those purchases. Assets Tracking reports show operational fleet counts; the books still flow through cash entries into the general ledger. Open an existing row with Edit on the list.

The Accounting module must be enabled under Integrations. Pair this screen with export batches or direct QB sync configured by your TenantAdmin. Terminology for GL and integration setup appears in Reference & glossary.

SCM → Accounting → Vendor bills (/inventory/bills) is AP (accounts payable) — what you owe suppliers after goods or services arrive. A vendor bill records invoice number, due date, line amounts, and tax, usually referencing the vendor master and optionally the PO and receipt that justify the spend.

Three-way match compares PO (what you agreed to buy), receipt (what you actually received), and bill (what the vendor invoiced). Matching catches price hikes, quantity overbilling, and duplicate invoices before cash leaves the bank. AP clerks approve bills that match within tolerance and escalate exceptions to purchasing.

Bills increase AP liability and, with Inventory accounting, may capitalize stock or expense consumables immediately depending on item setup. Payment happens in QuickBooks or your bank portal after bills export — inveazy tracks approval and open balance until paid.

Approved bills roll into AP export batches for QuickBooks. Open AP aging appears on the SCM purchasing dashboard. Buy-side context: Purchase orders → Receipts → vendor bill in End-to-end workflows.

SCM → Accounting → AP export batches (/inventory/ap-exports) groups approved vendor bills for push to QuickBooks Online (or your connected GL). A batch is a controlled release — finance reviews totals, posts the batch, and marks bills exported so they are not double-sent.

Export batches bridge operational SCM and the system of record accountants live in daily. Mapping vendor, account, class, and tax codes happens under Integrations; batches assume that mapping is stable before high-volume month-end closes.

Typical rhythm: AP approves daily or weekly bills in Vendor bills, builds a batch, exports to QuickBooks, then schedules payment in the bank or QB bill pay. Errors surface as sync failures with retry after fixing vendor or account mismatches.

AR has a parallel path via AR export batches. For GL terminology and connector setup, see Reference & glossary and End-to-end workflows (PO → receive → bill → QB).

SCM → Accounting → Invoices (/inventory/invoices) is AR (accounts receivable) — bills you send customers for shipped goods or services. Invoices translate fulfilled SO lines into money owed, due dates, and tax totals your bookkeeper collects against.

Best practice: invoice after shipment (or per contract milestones) so revenue matches delivery. Generate from a shipped sales order to pull quantities and pricing automatically; edit memos or freight lines as needed. Credit memos from Returns (RMA) reduce AR when customers send goods back.

Open invoices feed AR aging, dunning, and cash-flow forecasts on sales dashboards. Payment terms on Customers drive due dates (Net 30, etc.). Stripe or other gateways may collect card payments on web orders; desk invoices may still be paid by check or ACH recorded in QuickBooks.

Post approved invoices through AR export batches to QuickBooks. Sell-side flow: quote → SO → ship → invoice in End-to-end workflows. Integration fields live under Integrations.

SCM → Accounting → AR export batches (/inventory/ar-exports) sends approved customer invoices to QuickBooks in grouped batches, mirroring the AP export pattern on the buy side. Finance controls timing so month-end revenue matches operations' shipment cutoffs.

Each batch lists invoices, customers, totals, and tax; successful export marks rows synced and prevents duplicates. Customer and item mapping must exist in QuickBooks — configure defaults under Integrations before the first high-volume close.

Operations owns shipment truth; finance owns export timing. A common close rhythm: stop shipments at cutoff, verify Shipments, generate Invoices, review AR batch, export to QB, then reconcile deposits as payments arrive.

Pair with AP export batches for a full subledger picture. GL and acronym definitions: Reference & glossary. Narrative sell-side chain: End-to-end workflows.

SCM → Warehouse operations → Reorder alerts (/inventory/reorder-alerts) lists SKUs at or below their reorder minimum with on-hand, open purchase order quantity, and primary vendor. Buyers use it as a morning queue instead of scrolling the full product catalog.

Select rows and use Draft PO to create or merge lines into an open draft or pending purchase order per vendor — one click per supplier instead of re-keying SKUs. Pair with the Inventory dashboard low-stock KPIs and Purchase orders for approval and send workflows.

Reorder minimums are set per product (or category defaults). Alerts respect warehouse scope when filters are applied. Service SKUs and non-stocked items typically do not appear.

Open the phone icon in the top bar or go to SCM → Warehouse operations → Mobile (/inventory/mobile). The launcher grid groups Buy side flows (PO receive, putaway, lookup) and Sell side flows (pick, ship, count, transfer).

Each mode opens /inventory/mobile/scan/{mode} with camera or handheld barcode input. Common modes:

• Receive — post receipt lines against an open PO; optional license plate (pallet) for multi-PO dock receive
• Pick — confirm SO picks into a shipping staging bin; multi-line staging lets you scan several products then Commit once for a single GL loss journal on consumables
• Put-away — move received qty into a bin
• Count — cycle count by location
• Transfer / Track — move or trace inventory between bins
• Staging — scan an LPN or staging bin to move a whole pallet or break down and shelve contents
• Lic. plate — create/print LPN labels; scan an LPN to review linked POs, products, and pallet total
• Receipt capture — photo + details for non-PO receipts (/inventory/mobile/capture)

Desktop License plates lists pallet labels and staging bins. Shipped highlights: Changelog.

Mobile capture (/inventory/mobile/capture) is a separate phone-first wizard to add CRM organizations, contacts, and workspace accounts (customer, vendor, carrier) in the field — start with organization, then link contacts and accounts.

SCM makes the most sense as document chains that mirror real warehouse and accounting work. If you are new to ERP/WMS, memorize two flows first — sell side and buy side — then use the megamenu sections as drill-down detail. Start from the SCM menu overview if you have not read it yet.

Sell side: quote → SO → pick → ship → invoice

Sales drafts a Quote with SKU lines and price. On acceptance, convert to an SO (Sales orders). Warehouse picks against the SO — confirming bin and quantity, optionally using mobile scan — then posts a Shipment so on-hand drops. Finance generates an Invoice for AR; approved invoices export to QuickBooks via AR export batches. Storefront orders skip the quote step but follow SO → ship → invoice from Web orders. Short picks create Backorders; returns use RMA to reverse pieces of the chain.

Buy side: PO → receive → bill

Purchasing places a PO (Purchase orders) with a Vendor. When freight arrives, receiving posts a Receipt — stock increases in the target warehouse/bin, with FEFO data captured for perishables. AP enters a Vendor bill and performs three-way match against PO and receipt before approval. Batches export to QuickBooks through AP export batches. Consumables may bypass lengthy on-hand tracking if expensed on receipt.

Inventory integrity and GL

Between both flows, On-hand inventory reflects receipts, shipments, Transfers, and Cycle counts. Accounting posts inventory and COGS movements to the GL (general ledger) when enabled; QuickBooks remains the system of record for many small businesses after export. Read Accounting overview for how local GL, QuickBooks, Stripe, and Income & expenses work together; configure connectors under Integrations. Deeper acronym coverage lives in Reference & glossary.

Counter POS is the fullscreen till at /pos for in-person sales — coffee counters, farm stands, showrooms, and retail desks. It is separate from the public web store, desk-entered sales orders, and Assets Tracking’s dock inspection.

Open it from the Hub Apps tile Counter POS (or the phone-scanner launcher when the module is allowed). The till has no hub sidenav or megamenu — clerks stay in one screen for the shift.

A typical sale looks like this:

1. Attach a customer (search by phone or email) or use Walk-up when that option is enabled.
2. Add products (scan or search) and/or services from your till menu.
3. Optional: discount, shipping (registered customers with a ship-to ZIP), or hold the ticket for later.
4. Pay with cash or card (Stripe Reader S700/S710). Tips collect on the reader for card, or on the Pay panel for cash, when Accept tips is on.
5. Email or print the receipt, then start the next customer.

Paid POS sales create a sales order and paid invoice in Inventory — the same documents you already use for AR, web orders, and QuickBooks. Tips post as tip (not shipping). Local delivery should be a Services menu item, not a flat shipping fee.

Turn the module on

A TenantAdmin enables Counter POS under Admin → Integrations → Applications (pos). Each user’s role must allow the Counter POS application. Settings on the till (tax, tips, returns policy, service menus) are editable by TenantAdmin / Admin roles only.

Next: Settings & setup · Using the till · Stripe card readers

The till has three areas: a mode rail (or hamburger menu on iPad), a center workspace for the active mode, and a ticket on the right with lines and totals.

Layout & touch size

• Desktop — Full labeled rail; hamburger collapses it in place (page content shifts).
• iPad — No icon rail. Hamburger opens an overlay drawer; logo and page stay put. Ticket hides until a customer is attached (or held tickets exist so you can resume).
• Touch size (rail footer) cycles Desktop → iPad → Touch laptop for larger buttons.

Customer & registration

Search by phone or email and attach the match to the ticket. Use Registration for a new personal or commercial account (shipping + billing). When Allow walk-up customers is on (Settings → Registration), Customer shows a Walk-up control with an optional name for Hold / Open tickets. Walk-ups cannot use shipping.

Ticket, Hold, and Pay

• Lines, discount, shipping, tax, tip (after pay), and total live on the ticket.
• When Allow held / open tickets is on (Till settings), Hold parks the ticket on this browser; Open tickets resumes or discards held tabs.
• Pay opens cash and card tiles. Cash tips are on the Pay panel; card tips are on the reader when Accept tips is on.
• Lock (top bar) uses a session PIN; idle auto-lock keeps the till secure. Exit with Logout only.

See also Products, Services, Returns, and Card readers.

Open Settings from the till rail (TenantAdmin / Admin). Tabs match the modes you configure:

Till

• Which rail modes clerks can open.
• Use shipping — ticket Shipping uses the customer’s ship-to ZIP (not typed on the ticket).
• Allow held / open tickets — restaurant-style Hold tabs on this till.
• Tax on/off and state rate options used at checkout.

Registration

Allow walk-up customers for quick tabs without creating a full account. Looked-up and newly registered customers still carry phone, email, and addresses.

Products

Choose scan (barcode-first) or catalog / list browsing for the Products workspace. Product master data still lives in Inventory — see Products on the till.

Services

Build menus, categories, and priced items; set Accept tips and tip percent presets; choose tiles vs list layout. Full walkthrough: Services menus & tips.

Returns

Return window (days), restocking fee, whether a receipt is required, cash refunds, damaged-replace, and the POS returns location/bin. Details: Returns.

Recommended first-time checklist

1. Enable the pos module and confirm clerk roles can open Counter POS.
2. Configure Stripe commerce keys, then register a Location + S700/S710 (or use test mode simulated reader).
3. Set tax and Till options; turn on walk-ups and/or Hold if your counter needs them.
4. Stock products in Inventory; set Products layout on the till.
5. Build at least one Services menu if you sell labor, delivery, or non-SKU items.
6. Set Returns policy before the first in-store return.
7. Run a test cash sale and a test card sale; confirm the order appears under Web Orders / sales orders.

POS Services is a till menu of non-inventory sellables — consulting time, delivery, café add-ons, and similar. It is not Inventory “product type = service,” not the public storefront catalog, and not the hub appointments module.

Build a menu

1. Open Settings → Services.
2. Create or pick a menu (you can keep several versions; mark one as the till default).
3. Add categories, then items under each category.
4. Give each item one or more named prices (for example Small / Large, or Hourly). Drag to reorder.
5. Choose till layout: tiles (large Menu-view cards) or list (compact rows).
6. Save, then open Services on the till and confirm the default menu appears.

Clerks tap a price to add a line to the ticket. Lines post as invoice lines on the paid sales order — clean for AR and QuickBooks. Prefer a Services item named “Delivery” for local delivery instead of stuffing fees into shipping.

Tips

• Turn on Accept tips and set percent presets (default 15, 18, 20).
• Tip is not taxed. It stores as tip on the sales order and invoice (shown separately on receipts).
• Card: tip screen on the S700/S710 after the charge amount is known.
• Cash: tip chips and custom amount on the Pay panel (not on the open ticket).

Tip settlement to employees (payout) is a later step — today the till only collects tip with the sale.

Products sold at the till come from your Inventory product catalog — same SKUs you buy, stock, and sell online. Keep barcodes, prices, and on-hand accurate in SCM; the till only scans and searches them.

On the till

• Scan layout — Focus the scan box; wedge scanners type the barcode and Enter.
• Catalog / list layout — Browse or filter products, open detail, then add qty to the ticket.
• Adjust qty, remove lines, and apply ticket discount or shipping when those features are enabled.

After pay, the sales order and invoice show the same product lines. Shipping with a ZIP creates a confirmed order and a draft warehouse shipment for remaining lines when Use shipping is on.

Recommendation: use Products for inventoriable goods; use Services for labor, fees, and non-stock lines so inventory counts stay clean.

POS Returns looks up any paid sales order (POS cash/card or other channels) by order or receipt number within your configured window, then completes a return with restock or scrap and a refund.

Policy (Settings → Returns)

• Return window (days) and whether a receipt/order number is required.
• Restocking fee percent; optional waive when “customer not at fault.”
• Accept cash refunds; allow damaged → replace (scrap + no refund, hand a good unit).
• POS returns location / bin for serviceable restock.

Clerk flow

1. Open Returns → look up the paid order.
2. For each line, set qty and condition: serviceable (restock), damaged (scrap), or damaged — replace when allowed.
3. Complete the return. Card refunds go to the original Stripe PaymentIntent; cash is recorded and handed by the clerk when cash refunds are allowed.
4. A return receipt opens in the ticket Receipts viewer.

Returns use the same RMA machinery as Inventory Returns (RMA), with POS-friendly defaults.

Counter POS takes card via Stripe Terminal (server-driven card_present) using the same tenant commerce keys as online checkout. Use Chrome, Edge, or Safari on the till device (iPad or desktop).

Prefer Stripe Reader S710 when buying new hardware — typically the same purchase price as the S700, with optional 4G/LTE cellular (S700 is Wi‑Fi / Ethernet only). Cellular is useful for mobile businesses (markets, pop-ups, trucks) or Wi‑Fi failover; Stripe bills it separately (commonly about $10/month per reader for ~10 GB when enabled — confirm on Terminal pricing). Fixed counters with solid Wi‑Fi or Hub Ethernet can leave cellular off.

Online Stripe Checkout for invoices and the web store is covered under Stripe payments. This topic is only for in-person readers.

1. Commerce keys

You do not need a separate Terminal API key, reader ID, or Terminal webhook in Integrations. Use the same Stripe commerce secret and publishable keys as invoices and the web store. Card status on the till is driven by the app (server-side), not by Terminal-specific webhook events.

1. Open Admin → Integrations → Payments.
2. Enter the tenant Stripe publishable and secret keys (test sk_test_… for practice; live keys for production).
3. Save the usual Checkout/invoice webhook signing secret if you use online pay (unchanged for readers). Card on the till will not work without the API keys.

2. Location in Stripe Dashboard

1. Sign in to Stripe Dashboard (same mode — test or live — as your keys).
2. Go to Stripe Terminal → Locations (or search “Locations”).
3. Create a Location for the store or counter (name + address). Readers register to a Location.

3. Register the S700 / S710

1. Power on the reader and give it internet: store Wi‑Fi, optional Hub + Ethernet (reader prefers Ethernet when plugged in), or — on S710 only — Stripe cellular enabled on the Location (no separate carrier SIM; Stripe bills usage).
2. In Dashboard → Terminal → Readers, register the device to your Location (pairing / registration code as Stripe shows on the reader screen).
3. Confirm the reader shows as online. The till talks to Stripe over the internet (server-driven), so iPad and reader do not have to share the same Wi‑Fi — each just needs a reliable path to Stripe. Field tip: a travel router for iPad + reader still helps when guest Wi‑Fi isolates devices or blocks Terminal.

4. Take a card payment

1. On the till, attach a customer, add lines, open Pay → Card.
2. One online reader: the till uses it automatically. Two or more: the clerk picks (choice remembered for the session).
3. Customer taps, inserts, or swipes. If Accept tips is on, the tip screen appears on the reader after the charge amount.
4. When the payment succeeds, the till posts the sales order and paid invoice (notes include POS card) and can email/print the receipt.

Demo without hardware (test mode)

1. Use a test secret key on the tenant.
2. Tap Card — inveazy registers a simulated S700/S710 if none are online and presents a test card (Visa 4242…) for you.
3. With Accept tips on, the simulation can include a sample tip so receipts look realistic.

Tips sync

When Accept tips is on, inveazy updates the Stripe account-default Terminal Configuration with your tip percent presets so the reader tip UI appears. You can also set tip options in the Stripe Dashboard; inveazy presets are the recommended source of truth for the till.

Barcode scanners should act as a keyboard (HID wedge) into the Products scan box — they are separate from the Stripe reader.

Use Assets Tracking (sometimes labeled TRK in short menus) to manage expensive equipment your company owns — toolboxes, machines, vehicles, and similar gear. These are capital assets, not the everyday products you buy and sell from inventory.

Assets Tracking helps you answer four questions:

• What equipment do we own?
• Is it ready to leave the yard or dock?
• Where is it right now?
• When is the next service due?

Think of Assets Tracking as three kinds of work. Keep them separate so screens stay simple:

• Build — Create and edit assets, tool-set recipes, and categories. Use this when you add gear or change what is inside a box.
• Checkout / check-in — Inspect a unit before it leaves and when it returns. Record photos, meter readings, and missing items. This is an inspection desk, not a cash register.
• Schedule, map, and support — Send gear to a job site, consignment, or rental; pin it on the map; plan maintenance; and review reports.

A TenantAdmin turns Assets Tracking on under Admin → Integrations → Applications. Each user’s role must also allow the Assets Tracking application. Products you sell to customers stay in supply chain inventory. Capital units never become warehouse on-hand stock.

Home location vs placement site

Every asset has a home location — where it usually lives when it is not out. A placement site is where it is deployed today (a job address, customer site, or rental location). Placing or returning gear does not change the home location. Saving a pin on the map updates GPS coordinates only.

The Assets Tracking hub is the home page for this module. It shows shortcuts to capital assets, tool sets, checkout, schedule, map, maintenance, categories, and reports.

Open the hub when you are not sure which screen to use next, or when you want a quick jump to the main Assets Tracking tools.

Capital assets is the list of equipment you own. Each row is one physical unit with an asset number (tag), category, status, home location, and an optional person responsible for it.

Open an asset to edit its details, contents, notes, QR label, and photos. Use this screen to build or adjust the unit. To send it to a customer or job site, use Schedule & place instead.

Small hand tools and disposable supplies belong in Products and inventory, not here. After a toolbox is built, change it only when the contents actually change.

Tool sets are reusable recipes — lists of products that make up a standard toolbox, kit, or reorder pack. They are templates, not the physical boxes sitting in the yard.

Create a tool set once, then copy it onto a capital asset when you build a real unit. You can also use a tool set to start draft purchase orders, sales orders, or quotes with the same product lines.

Checkout / check-in is the dock inspection for capital equipment. Use it before a unit leaves and when it comes back. It is not a point-of-sale screen for selling products.

During an inspection you can record the date and time, take photos (webcam or phone — files land in File Manager under TRK / Checkout), capture mileage or hours and fuel, note condition and damage, and mark expected contents that are missing.

• Checkout (out) — Inspect before the unit leaves. Afterward, place it on Schedule & place so the system knows where it went.
• Check-in (in) — Inspect on return. Leave Return active placement checked (the default) so the open placement is closed and the schedule and map stay accurate.

Under Recent inspections, select a row to open the full saved inspection below the list.

Schedule & place records where equipment is deployed. You can place a unit on a job site, as consignment, or as a rental.

For each placement, choose the customer account, contact, and custodian if needed. Set a due-back date when you expect the gear to return. Enter the placement location / site — the address where the unit is working today. That address is separate from the asset’s home location.

Use Checkout / check-in for the dock inspection. The schedule screen is for movement and due dates, not for condition photos.

The Map page shows your capital assets on a map when GPS coordinates are available (Mapbox must be configured for your workspace).

Popups and the detail card list both the home location and the current placement site. When you save a pin, only the latitude and longitude are updated. The home location does not change. To change where the unit is deployed, edit the placement on Schedule & place.

Maintenance plans and records service on capital assets — preventive work, inspections, and repairs. You can schedule upcoming work and log what was done, including costs and file attachments.

When you log service against a schedule, the next due date moves forward automatically. Tool-set recipes are templates only. Always maintain the physical asset under Capital assets, not the recipe.

Reports gives you an operational view of the fleet. Summary cards show how many assets you have, how many are out on placements, which returns are overdue, how many are on rent, which maintenance items are overdue, and which warranties end within the next thirty days.

Tabs below the summary break the data down by status or category, by customer account, by placement, by maintenance due, and as a full asset roster.

Calibration “out of cal” reporting is not available yet. Assets Tracking reports do not replace the financial books. To record the purchase of capital equipment in accounting, use Income & expenses with a capital category such as 1500 Fixed Assets.

Asset categories classify your equipment — for example toolset, laptop, or vehicle. Categories appear on create forms and in list filters so you can group similar gear.

Asset statuses (available, placed, and so on) are shared lookups maintained by the system. You manage category names here when your workspace needs new equipment types.

inveazy is built AI-ready: a first-class Workspace assistant sits beside CRM, PM, SCM, and Hub apps — not bolted on as an afterthought. The assistant can answer product questions, draft blog HTML, produce table-first executive reports, and (when your administrator enables it) ground answers in live workspace data scoped to the module you are working in.

Open it from the top bar HUB → Assistant → Workspace assistant (/apps/assistant) or from shortcut cards on the Hub overview. This Help group documents how to use and configure it; operational business data still lives in CRM, PM, and SCM screens.

What makes it different

• Module scopes — pick CRM, PM, Blog, File manager, Dashboard, or General so prompts only see data that belongs in that context.
• Read-only MODULE SCOPED DATA — optional sanitized snapshots attached to prompts so the model cites real pipeline, work items, or posts instead of guessing.
• Workspace rules & built-in templates — tenant-wide instructions plus locked formats for rich HTML reports and Quill-ready blog drafts.
• BYOK or built-in models — use the host’s Azure OpenAI endpoint or bring your own OpenAI, Anthropic, or Gemini key under Integrations → AI assistant.
• Honest boundaries — when data is not loaded, answers should say so and mark uncertain cross-module claims with [VERIFY].

The full user guide — scopes, models, reports, privacy — is in Workspace assistant. Administrators configure the Assistant application toggle, API keys, and read-only data on the Applications and AI assistant tabs of Integrations.

HUB → Assistant → Workspace assistant (/apps/assistant) is an AI chat panel for your workspace. You can ask how inveazy features work, draft text, brainstorm ideas, or — when configured — request summaries grounded in live CRM, PM, or blog data. It is not a replacement for clicking through modules; it is a conversational layer on top of the same tenant you already signed into.

The page has three regions. On the left, Scope chooses which module context the assistant may use (General, CRM, PM, Blog, File manager, Notifications, Calendar, Dashboard, and others your administrator enabled). In the center, the thread shows the conversation. On the right, tabbed panels let you write a message, pick a model, edit workspace rules, inspect built-in report templates, and read the in-app guide. Pick a scope first, then send from the Message tab — the empty state reminds you of that order.

If the assistant is disabled, the center panel explains why and links to Admin → Integrations. A TenantAdmin must enable the Assistant application and configure AI under the AI assistant tab before chat works. Until then, non-administrators see a friendly blocked state rather than a broken send button.

Bring your own key (BYOK) and models

inveazy supports two ways to connect to large language models. The host may provide a built-in endpoint (Azure OpenAI or similar) managed by the platform operator. Alternatively, your workspace can use bring your own key (BYOK) — you paste an API key from OpenAI, Anthropic, Google Gemini, or another supported provider under Integrations → AI assistant. BYOK bills go to your provider account; the built-in path bills the host.

End users choose a Model on the assistant's right rail (stored per browser). Pricing hints in the Guide tab are approximate list prices for planning only. Admins set which providers and model names are allowed. Never paste API keys into the chat box — use Integrations, which stores secrets encrypted and does not show them again after save.

Scope and read-only workspace data

General scope answers from public knowledge plus any workspace rules you configured — not from live database rows. To ask How many open opportunities do we have? or Summarize this week's PM work items, select the matching module scope (CRM, PM, etc.) and ensure Allow read-only workspace data is on in Integrations. That toggle lets the server attach a sanitized MODULE SCOPED DATA block to your prompt. Without it, the model must not invent counts; it should tell you data was not loaded.

Read-only SQL access (optional AppHubAssistantRead login) is documented under Integrations → Read-only database. It is related but distinct: scoped data in chat is curated per module, while the SQL login is for Power BI or SSMS reporting. Both respect tenant isolation.

Workspace rules and built-in templates

The Rules tab holds custom instructions for your tenant — tone, terminology, boundaries (for example do not quote prices), and optional module-data rules. Admins edit these once; every user inherits them. The Built-in tab shows locked templates such as Report / export — rich HTML output and Blog draft — Quill-ready HTML that shape how answers are formatted when you request reports or blog content.

The Guide tab summarizes costs, scope behavior, and links back to Integrations. Use Clear history in the header if a thread becomes slow or stuck; that deletes saved chat messages for your user without changing workspace settings.

HTML reports and prompt templates

When you ask for a report, status summary, or executive summary, the assistant can reply with formatted HTML instead of plain text. Built-in report rules enforce a table-first layout: title, date, numbered table of contents, KPI cards, status badges, and short prose after each table. PM-focused prompts cover project status, phase progress, risk analysis, resource capacity, and weekly standups. CRM prompts cover pipeline forecasts, activity follow-ups, and account reviews. Say quick report or one-pager for a shorter template.

Reports should only cite rows present in MODULE SCOPED DATA. The model marks uncertain cross-module guesses with [VERIFY]. You can print or copy the HTML into email; for blog drafts, switch to Blog scope and use prompts that output Quill-compatible HTML (no Markdown fences). The Blog hub also links to /apps/assistant?scope=blog for review workflows.

Privacy and support boundaries

Do not share passwords, payment card numbers, or private API keys in chat. The assistant should redirect secret management to Integrations. It must not invent inventory quantities, pipeline dollars, or customer names when scoped data is missing. For account-specific escalations, contact your TenantAdmin.

Configure AI under Integrations, enable the Assistant app on the Applications tab, and pair this guide with Blog hub when drafting posts. For module business data without AI, use CRM and PM dashboards directly. Start with Assistant overview for the product-level AI story.

Use this page when you encounter an unfamiliar acronym in SCM, CRM, or admin screens. Terms are grouped loosely by topic. For narrative walkthroughs, open the matching item in the SCM, CRM, or Admin sidebar groups.

Platform

Term	Definition
Tenant / workspace	Isolated organization environment on one install — own users, data, modules.
Module	Functional app area (CRM, PM, Inventory) enabled per workspace.
RBAC	Role-based access — roles bundle module permissions assigned to users.
TenantAdmin	Workspace administrator — users, integrations, branding, provisioning.
BYOK	Bring your own key — tenant-supplied AI API key for the assistant.

SCM documents

Term	Definition
PO (purchase order)	Commitment to buy from a vendor; drives receiving and AP matching.
SO (sales order)	Customer order to fulfill; drives pick, ship, and invoicing.
Quote	Non-binding offer to a customer; may convert to an SO.
Receipt	Inbound document posting stock from a PO (or ad hoc receive).
Shipment	Outbound pick/pack/ship against an SO; reduces on-hand.
Transfer	Stock move between warehouses or bins without a sale or PO.
RMA / return	Customer return authorization — restock, scrap, or refund path.
Cycle count	Physical count vs system qty; variances post adjustment journals.

Warehouse & inventory

Term	Definition
SKU	Stock keeping unit — product identifier you buy, stock, and sell.
Warehouse	Physical or logical site holding inventory (MAIN, secondary DC).
Location / bin	Address inside a warehouse (aisle, shelf, pallet position).
On-hand	Quantity physically available by product, warehouse, and bin.
Lot	Batch identifier for traceability (often with expiration).
FEFO	First-expired, first-out — pick order favors soonest expiry dates.
Backorder	Demand or supply shortfall — SO line waiting for stock or PO line waiting for vendor.
Standard cost	Planned unit cost for GL inventory valuation and COGS.
Consumable	Product type for internal-use items (gloves, labels) issued without an SO.

Accounting

Term	Definition
AR (accounts receivable)	Money customers owe you — customer invoices.
AP (accounts payable)	Money you owe vendors — vendor bills.
GL (general ledger)	Chart of accounts and posted journal entries in Acct_Journal.
Three-way match	AP control: PO + receipt + vendor bill quantities and costs align.
COGS	Cost of goods sold — expense when shipped stock leaves inventory.
GR-IR	Goods received / invoice received clearing account on PO receipt posting.
Export batch	Grouped AR or AP documents pushed to QuickBooks Online.

CRM & PM (short)

Term	Definition
Account	CRM sell-to customer company (not a tenant workspace).
Opportunity	Active deal with amount, stage, and close date.
Work item	PM task/bug/story with status, assignee, and dates.
Sprint	Time-boxed PM iteration grouping work items.

inveazy grows in phases. The table below lists modules that are still planned. For what you can use today — including Counter POS and Stripe Terminal card readers — see Getting started, Changelog, or /about.

QuickBooks Online and Stripe integrations are available for many tenants today under Integrations. This roadmap lists net-new modules still to come; shipped work is in Changelog.

High-level shipped highlights — newest first. This is not a per-commit log; it summarizes releases that matter to tenants. Planned work lives under Roadmap (in Getting started) and on /about.

1. 2026-08-07

   Counter POS — till, Terminal card, services & returns

   • Fullscreen Counter POS at /pos (Hub Apps tile): customer search and registration, optional walk-ups, products (scan or catalog), and a right-hand ticket with discount, shipping, Hold / Open tickets, and clerk PIN lock.
   • Cash and Stripe Terminal card pay (server-driven). Same commerce keys as Integrations → Payments. Physical S700/S710 via Stripe Dashboard Location; test mode uses a simulated reader. Tips on the reader (card) or Pay panel (cash) when Accept tips is on.
   • Services menus in Settings: categories, items, named prices, tiles/list layout, tip presets. Delivery and other non-SKU lines belong on the services menu — not folded into shipping.
   • Product returns from paid orders (POS or otherwise): restock/scrap/replace, cash or card refund, return receipt in the ticket viewer.
   • iPad-friendly till: hamburger overlay rail, ticket stays reachable when held tabs exist, products/services use most of the workspace column.
   • In-product Help: Counter POS group (overview, till, settings, services, products, returns, Stripe readers). Roadmap and About updated for the shipped till.
2. 2026-08-03

   Assets Tracking for capital equipment

   • Assets Tracking is available as its own application. Use it for owned equipment such as toolboxes, machines, and vehicles — not for products you sell from inventory.
   • Build capital assets and reusable tool-set recipes, organize them with categories, and open everything from the Assets Tracking hub and menu.
   • Checkout and check-in capture a dock inspection with photos, meter readings, and missing items. This is not a cash register. On check-in you can close the open placement so the schedule and map stay current.
   • Schedule & place sends gear to a job site, consignment, or rental. The asset keeps its home location; the placement holds the site where it is working today.
   • Map pins, maintenance schedules and service logs, and Assets Tracking reports (summary counts, placements, overdue returns, rentals, and maintenance due) are included.
   • Income & expenses can post capital purchases to accounts such as 1500 Fixed Assets, and you can edit an existing cash entry from the list.
3. 2026-07-27

   Go-live image, QB assessment & provision preflight

   • inveazy image live on platform hosts (GL8); landing, billing, and subscribers polish continues with daily image updates.
   • QuickBooks App assessment submitted in Intuit Developer Portal; production keys and per-host OAuth redirects.
   • Provision preflight (NS25): slug/DB clash checks against catalog, provision jobs, and Stripe subscribers — Admin Start, paywall Checkout, and live slug check in Set up your install.
   • Customer commerce Stripe BYOK: Integrations → Payments secrets preferred over host Stripe env for Checkout and webhooks.
   • Pricing page: larger install modal; compare plans lists CRM, Project Management, SCM, and Accounting as separate rows; capacity glossary cards use neutral styling.
4. 2026-07-24

   Azure SaaS provisioning

   • Paywall → Stripe Checkout → Hivoltech Azure provision (SQL + Container App + DNS); ops Subscribers console with Retry and welcome email.
   • In-app Admin Billing: platform subscription, soft-lock/grace, workspace capacity updates without double Azure charges.
   • Ops Subscribers dashboard: Stripe MRR income KPIs; Azure expense/margin reserved for Cost Management auto (no manual cost entry).
5. 2026-07-24

   Customer website customization

   • Public site branding for customer installs: turn off inveazy marketing sections (capabilities, integrations, Pricing, demo signup, Info navbar); keep Blog/Shop when wanted.
   • Landing blocks editor: ordered sanitized HTML sections after the hero, Theme & samples (HyperUI / OpenTailwind), optional navbar buttons with section ids, constrained/wide layout.
   • Contact-form destination email on Home hero (inline with Primary button URL when action is URL).
6. 2026-07-16

   License plates (LPN) & staging bins

   • WMS license plates: create/print pallet labels, assign warehouse location and zone, edit staging bin.
   • Mobile Lic. plate mode: scan LPN to view linked POs, product details (Inv#, vendor, Mfg#, UOM, unit price), and pallet grand total.
   • Mobile Staging: scan LPN or staging bin to move whole pallets or break down and shelve contents.
   • Receive-to-LPN on mobile: multiple POs on one sealed pallet with print label and close-pallet flow.
   • Shipments: picked status (draft → picked → packed → shipped) and shipping-staging bins after pick.
7. 2026-07-14

   Help, dashboards & platform docs

   • Help: Tenant Admin vs Admin split; Buy/Sell/Accounting/Storefront groups; Roadmap and Changelog.
   • Tenant Admin docs: Demo vs SandBox, per-workspace self-registration, public branding stored in SQL.
   • SCM help: reorder alerts, mobile scanner, throughput KPIs on sales/inventory dashboards.
   • Inventory dashboard: calendar-quarter variance; slow movers exclude consumables.
   • Financial dashboard charts aligned to inveazy design palette.
8. 2026-07

   Help library, storefront & fulfillment

   • In-product Help at /help with collapsible sidebar groups matching megamenus; About inveazy catalog.
   • B2B storefront V1: web checkout, customer profile, staff web-order fulfillment queue.
   • Sales order / pick list / mobile scanner hardening; Stripe webhooks and redirect URLs.
   • Inventory dashboard, order mapping updates, and returns (RMA) system.
   • CRM customer updates; landing page and new-user onboarding polish; workspace assistant updates.
9. 2026-06

   SCM dashboards, mobile warehouse & labels

   • Sales, purchasing, inventory, and financial analytics dashboards; Stripe fee visibility.
   • Mobile scanner menu: receive, pick, put-away, count, transfer, and track flows (camera / wedge).
   • Cycle counts with QuickBooks-aware posting; income & expense cash entries.
   • Product labels, Kanban barcodes/QR, ZXing scan stack, and print product sheets.
   • Bulk product upload with template; AP export batches and bill-pay setup.
   • Order confirmation emails and PO layout improvements.
10. 2026-05

    Accounting, integrations, hub apps & assistant

    • Local GL path: invoices, vendor bills, cash entries, AR/AP export; order/invoice email processes.
    • QuickBooks Online OAuth/sync and Stripe platform + tenant checkout integrations.
    • Workspace assistant (AI) V1: module-scoped chat, model options, HTML report writer.
    • Hub apps: file manager, notifications inbox/email, calendar, and blog authoring/read.
    • Org branding, PWA/icons, multi-tenant registration, and read-only SQL tenant login for reporting.
    • SCM document chain foundations (PO → receive → SO → ship) and Docker packaging fixes.
11. 2026-04

    CRM, project management & platform shell

    • CRM milestone: organizations, accounts, contacts, pipeline/Kanban, activity boards, deals, and CRM dashboard.
    • Project management: projects, work items, Kanban boards, Gantt chart, and demo data.
    • inveazy replaces the separate API host — signed-in Razor shell, auth, and Scalar in production.
    • CRM frontend + APIs/DTOs; theme system, gulp/CSS pipeline, and static asset map.
    • Docker Compose, Azure Pipelines CI, container registry, and Azure SQL publish path.
    • User manager and login / password-reset flows for workspace users.
12. 2026-03

    Foundation — database, API & warehouse schema

    • Solution bootstrap: AppHubDb SSDT project, git root, and initial database build.
    • Core schema and SQL tests; early warehouse management docs and product catalog tables.
    • inveazy API setup and integration tests (later folded into inveazy).
    • Docker and Azure pipeline scaffolding to run the database with the app.
    • Backlog and schema spikes for assets, HR, and AI tables ahead of module work.
13. 2026-03-30

    Project started

    First commits landed this evening (Pacific): .gitignore, project files, init/db, then the initial AppHubDb build the next day. Everything above grew from that foundation.