Setup

Metadata reference

Temporary

API names and metadata rules

A customer-facing reference for how standard, custom, and imported objects and fields are named and represented in the current CRM.

FirstHour Data PlatformAuthoritative service boundary

All data access passes through the platform

FirstHour CRM and external integrations use the FirstHour Data API or SDK. The platform authenticates the caller, resolves its tenant and environment, checks scopes and rate limits, validates names and payloads, applies business rules, records an audit trail, and only then reads or writes Supabase. Supabase remains the final integrity boundary through RLS and database constraints; callers never receive direct database credentials.

FirstHour CRM / integrations→FirstHour Data API→FirstHour Data Platform→Supabase

Public contract: https://api.example.com/v1 · OpenAPI document: https://api.example.com/openapi · JavaScript package: @firsthour/sdk

How an external integration connects

A company administrator first registers an API Client in Setup. Each client represents one connected application and is restricted to its selected tenant, environment, scopes, expiration, and rate limit.

1
Register an API Client
In Setup → API Clients, enter a recognizable name such as ERP Production and approve only the scopes it needs.
2
Store the credentials securely
FirstHour issues a client_id and one-time client_secret. The secret belongs in the integration's server-side secret manager, never browser code.
3
Request an access token
Send the credentials with grant_type=client_credentials to POST https://api.example.com/oauth/token. The platform returns a short-lived, scoped token.
4
Call the Data API
Send Authorization: Bearer <access_token> to routes such as GET /v1/records/account. Clients never connect directly to Supabase.

Access tokens expire after one hour. Integrations should cache a token server-side until shortly before expiry, request a new one when needed, and rotate or revoke an API Client immediately if its secret is exposed.

API examplesPostman ready

Sample URL calls

During testing, use https://nativecrm-kappa.vercel.app/api as the base URL. Record requests require Authorization: Bearer <access_token> and JSON writes require Content-Type: application/json.

POST

https://nativecrm-kappa.vercel.app/api/oauth/token

Exchange the service-account credentials for a one-hour access token. Send as x-www-form-urlencoded.

grant_type=client_credentials
client_id=<client_id>
client_secret=<client_secret>
scope=records.read records.write

GET

https://nativecrm-kappa.vercel.app/api/v1/records/account?limit=50

List up to 50 Account records. Requires records.read.

GET

https://nativecrm-kappa.vercel.app/api/v1/records/account/7BC1DED566A8753AA018DB2538

Retrieve one Account using its public record ID. Lowercase IDs are accepted too.

GET

https://nativecrm-kappa.vercel.app/api/v1/records/contact/07EED42762D0EE644A8CD20EF9

Retrieve one Contact using its public record ID. Requires records.read.

POST

https://nativecrm-kappa.vercel.app/api/v1/records/account

Create an Account. The response returns its immutable 26-character public ID. Requires records.write.

{
  "name": "Northstar Manufacturing",
  "externalId": "northstar-001"
}

POST

https://nativecrm-kappa.vercel.app/api/v1/records/contact

Create a Contact. Use API field names in the JSON body. Requires records.write.

{
  "firstname": "Avery",
  "lastname": "Morgan",
  "email": "avery@example.com",
  "externalId": "northstar-contact-001"
}

Postman setup

Run the token request first and copy access_token from the response.
For record calls, choose Authorization → Bearer Token and paste the token.
Use GET to read records and POST to create records. GET requests do not need a body.
The private Supabase UUID is never accepted as a public record URL identifier.

Regional data architectureProduction and Sandbox are physically separated

How regional Production and Sandbox data flows

Customers choose a data residency region at signup. FirstHour assigns their Production environment to that region's shared Production Supabase project and every sandbox to the matching shared Sandbox project. Projects are prepared in advance; signup provisions tenant and environment placement records rather than creating a database per customer.

1. Customer chooses data residency

US · UK · EU · India · Australia

2. Control-plane placement registry

tenant_id · environment_id · environment_kind · data_region · cell_id

US East

us-east-1
prod + sandbox

United Kingdom

eu-west-2
prod + sandbox

European Union

eu-central-1
prod + sandbox

India

ap-south-1
prod + sandbox

Australia

ap-southeast-2
prod + sandbox

Each pair consists of two separate Supabase projects/databases. Multiple tenants share a regional cell, while tenant_id, environment_id, indexed query boundaries, and RLS provide isolation inside that cell.

Production request flow

access token → environment_id → region + production cell → tenant boundary → Production records

Production tokens can resolve only to a Production cell. Sandbox imports and refreshes cannot consume the Production database's CPU, I/O, vacuum, or connection capacity.

Sandbox request flow

access token → environment_id → region + sandbox cell → tenant boundary → Sandbox records

Sandbox display names can be QA, UAT, Developer 1, or anything else. Routing never depends on the name; it uses immutable environment_id and cell_id.

Physical storage contractPlatform and Custom records

Where Account, Contact, and custom records are stored

Platform objects such as account and contact, together with Custom objects, share the polymorphic PostgreSQL table public.crm_api_records. The object API name selects the logical object, while the JSONB data column stores that object's field values. The API exposes only the immutable public_id; the PostgreSQL UUID remains private. Public IDs are globally unique 26-character ULIDs, allocated to one record for its lifetime, and never reused. They are stored in uppercase, while API lookups accept either uppercase or lowercase. Imported objects are the exception: they query their mapped source table directly.

Core columns in public.crm_api_records

Column	Purpose	Example
`id`	Private PostgreSQL UUID used only for internal joins; never returned by the API	`Hidden`
`public_id`	Immutable customer-facing ULID returned as `id`	`7BC1DED566A8753AA018DB2538`
`tenant_id`	Tenant isolation boundary	`t_halden`
`environment_id`	Production or sandbox placement	`env_halden_prod`
`object_api_name`	Logical object discriminator	`account` or `contact`
`data`	Field values keyed by field API name	`{ "name": "…" }`
`external_id`	Optional integration identifier	`demo-account-northstar`
`version`	Optimistic concurrency version	`1`
`deleted_at`	Soft-delete marker; active queries require null	`null`

Current test records

Live identifiers from the Halden production test environment; record field values are intentionally omitted.

object_api_name	public_id (API id)	external_id	tenant_id	environment_id
account	7BC1DED566A8753AA018DB2538	demo-account-northstar	t_halden	env_halden_prod
contact	07EED42762D0EE644A8CD20EF9	demo-account-northstar-contact-1	t_halden	env_halden_prod

Query boundary

tenant_id = 't_halden'
environment_id = 'env_halden_prod'
object_api_name = 'account'
deleted_at IS NULL

Primary access paths

(tenant_id, environment_id, object_api_name, created_at, id)

(tenant_id, environment_id, object_api_name, external_id)

Queries always begin at the tenant and environment boundary. Active-record reads also exclude rows where deleted_at is set.

Supabase project naming convention

Launch: 10 projects

Use fh-{aws-region}-{class}-{cell-number}. The region is the exact provider location, class is prod or sandbox, and the two-digit cell number allows horizontal expansion without renaming. Supabase's generated project reference is stored separately.

Project name

fh-eu-west-2-prod-01

Control-plane cell ID

cell_eu_west_2_prod_01

Future capacity cell

fh-eu-west-2-prod-02

Initial regional project inventory

Five customer choices, each with physically separate Production and Sandbox projects.

Customer choice	Provider region	Production project	Sandbox project	Placement note
United States	`us-east-1`	`fh-us-east-1-prod-01`	`fh-us-east-1-sandbox-01`	Current US East project becomes the first Production cell.
United Kingdom	`eu-west-2`	`fh-eu-west-2-prod-01`	`fh-eu-west-2-sandbox-01`	London is a separate residency option, not EU residency.
European Union	`eu-central-1`	`fh-eu-central-1-prod-01`	`fh-eu-central-1-sandbox-01`	Frankfurt provides the initial EU-member location.
India	`ap-south-1`	`fh-ap-south-1-prod-01`	`fh-ap-south-1-sandbox-01`	Mumbai provides the initial India residency option.
Australia	`ap-southeast-2`	`fh-ap-southeast-2-prod-01`	`fh-ap-southeast-2-sandbox-01`	Sydney provides the initial Australia residency option.

Future regional implementation

Create on demand

Do not show these signup choices until both projects are provisioned, migrated, monitored, and approved for customer placement.

Future market	Provider region	Production project	Sandbox project
US West (Oregon)	`us-west-2`	`fh-us-west-2-prod-01`	`fh-us-west-2-sandbox-01`
US West (Northern California)	`us-west-1`	`fh-us-west-1-prod-01`	`fh-us-west-1-sandbox-01`
US East (Ohio)	`us-east-2`	`fh-us-east-2-prod-01`	`fh-us-east-2-sandbox-01`
Canada	`ca-central-1`	`fh-ca-central-1-prod-01`	`fh-ca-central-1-sandbox-01`
Ireland	`eu-west-1`	`fh-eu-west-1-prod-01`	`fh-eu-west-1-sandbox-01`
France	`eu-west-3`	`fh-eu-west-3-prod-01`	`fh-eu-west-3-sandbox-01`
Switzerland	`eu-central-2`	`fh-eu-central-2-prod-01`	`fh-eu-central-2-sandbox-01`
Sweden	`eu-north-1`	`fh-eu-north-1-prod-01`	`fh-eu-north-1-sandbox-01`
Singapore	`ap-southeast-1`	`fh-ap-southeast-1-prod-01`	`fh-ap-southeast-1-sandbox-01`
Japan	`ap-northeast-1`	`fh-ap-northeast-1-prod-01`	`fh-ap-northeast-1-sandbox-01`
South Korea	`ap-northeast-2`	`fh-ap-northeast-2-prod-01`	`fh-ap-northeast-2-sandbox-01`
South America (Brazil)	`sa-east-1`	`fh-sa-east-1-prod-01`	`fh-sa-east-1-sandbox-01`

Signup and environment provisioning

Customer selects a supported residency region.
The control plane stores immutable data_region on the tenant.
Production is assigned to that region's Production cell.
Every sandbox is assigned to the matching Sandbox cell by default.
Each environment receives an immutable environment_id and cell_id.
Service accounts and tokens are bound to exactly one environment.

Data that must remain in-region

CRM records and custom object data
Files, attachments, and object storage
API logs or audit entries containing customer data
Database backups, replicas, and disaster-recovery copies
Background-job payloads and exports

The global control plane retains only minimal routing and operational metadata. It must not become a second copy of customer record data.

Controlled region migration

Never a settings toggle

1. Prepare

Validate destination schema, capacity, keys, retention, and residency contract.

2. Copy and verify

Snapshot and copy data, files, and required logs; reconcile row counts, checksums, and public IDs.

3. Cut over

Pause writes, apply the final delta, atomically change cell_id, and rotate environment credentials.

4. Retire source

Verify traffic and jobs, observe a defined rollback window, then securely delete source copies and backups per policy.

Public record IDs, API names, URLs, and automation contracts do not change during migration. Production and sandbox environments are migrated independently unless the customer requests a coordinated move.

Infrastructure strategy: Supabase first, portable PostgreSQL

Implement the boundary now

FirstHour launches its regional cells on Supabase for managed PostgreSQL, RLS, backups, storage, and lower operational overhead. Core record storage remains portable PostgreSQL so a future cell can move to Aurora PostgreSQL without changing public IDs, API URLs, metadata contracts, or customer integrations.

Implement before adding the second database

A server-only cell_id resolver maps an environment to one approved cell.
Business services request a database client from the resolver; they never read Supabase URLs or service keys.
Cell credentials stay in a secure registry and are never stored on tenant or record rows.
Control-plane models contain placement and lifecycle metadata only.
Automated schema-version, metadata-version, health, and migration checks gate placement.

Implement when regional projects are provisioned

Register each Production and Sandbox project as a cell.
Deploy identical migrations and seed approved metadata.
Enable signup placement only after readiness checks pass.
Add per-cell monitoring, backup verification, throttling, and capacity thresholds.
Maintain a tested Supabase-to-Aurora cell migration path as the fleet grows.

Control plane and regional data plane

Authentication decides who and where; the regional data plane stores customer content.

Global control plane

Minimal metadata

Users, organizations, sessions, and authentication policy
Tenant residency choice and environment-to-cell placement
Cell catalog, readiness, schema version, and routing status
Billing and operational lifecycle state

Must not store CRM records, files, payload-bearing logs, or regional backups.

Regional data plane

Customer data

CRM and custom-object records
Tenant metadata packages, layouts, rules, and automations
Files, attachments, exports, and background-job payloads
Regional API and audit logs containing customer data

Every query still enforces tenant_id and environment_id inside the selected cell.

Architecture contract

Production and Sandbox data never share a database. Region selection controls placement, arbitrary environment names never control routing, and all cells expose the same schema and API. Dedicated tenant projects remain an exceptional enterprise placement—not the default regional model.

Naming rules

Labels can change; API names are stable identifiers used by integrations and automation.

Kind	Rule	Examples
Standard	Platform-owned object and field names use stable lowercase identifiers.	`account` `ownerid`
Custom	Custom table and field API names use snake_case with the `x_` prefix.	`x_projects` `x_health_score`
Imported	Keep the connected source table and column identifiers; they are not renamed.	`orders` `customer_id`
System fields	Managed by the platform or source. They can be required or unique and should not be repurposed.	`id` `CreatedById` `created_at`

UI vocabulary

Administrator-facing terms used throughout FirstHour. API contracts may retain technical object and field identifiers.

Concept	Term
Entity	Table
Row	Record
Column	Field
Relationship	Link
Owned relationship	Parent-child
Validation rule	Check
Required	Required (toggle label)
Dropdown list	Choice list
Page layout	View

Tables in this workspace

Current label, API name, ownership, source, and field count.

Table	API name	Kind	Source	Fields
Account	`account`	Standard	native	24
Contact	`contact`	Standard	native	31
Opportunity	`opportunity`	Standard	native	27
Case	`case`	Standard	native	22
Invoice	`invoices`	Imported	billing.invoices	18
Invoice Line	`invoice_items`	Imported	billing.invoice_lines	11
Shipment	`shipments`	Imported	public.shipments	16
Warehouse	`warehouses`	Imported	import	9
Onboarding Project	`x_onboarding_project`	Custom	native	14
Employee	`employees`	Imported	public.employees	12
Customer	`customers`	Imported	public.customers	6
Order	`orders`	Imported	public.orders	5
Order item	`order_items`	Imported	public.order_items	5
Product	`products`	Imported	public.products	5
Subscription	`subscriptions`	Imported	public.subscriptions	5
Project	`x_projects`	Custom	native	4
Site	`x_sites`	Custom	native	4
Risk	`x_risks`	Custom	native	4
Note	`note`	Standard	native	4

Fields in this workspace

The implemented field metadata, including data type and behavior.

Table	Field label	API name	Data type	Origin	Checks
`account`	Account Name	`name`	text	Standard	Required · System managed
`account`	Account Number	`accountnumber`	autonumber	Standard	Unique · System managed
`account`	Account Owner	`ownerid`	lookup	Standard	Required · System managed · → user
`account`	Parent Account	`parentid`	lookup	Standard	→ account
`account`	Type	`type`	picklist	Standard	Optional
`account`	Industry	`industry`	picklist	Standard	Optional
`account`	Annual Revenue	`annualrevenue`	currency	Standard	Optional
`account`	Employees	`numberofemployees`	number	Standard	Optional
`account`	Phone	`phone`	phone	Standard	Optional
`account`	Website	`website`	url	Standard	Optional
`account`	Billing Street	`billingstreet`	textarea	Standard	Optional
`account`	Billing City	`billingcity`	text	Standard	Optional
`account`	Billing Country	`billingcountry`	picklist	Standard	Optional
`account`	Shipping City	`shippingcity`	text	Standard	Optional
`account`	Shipping Country	`shippingcountry`	picklist	Standard	Optional
`account`	Description	`description`	textarea	Standard	Optional
`account`	Customer Since	`x_customer_since`	date	Custom	Optional
`account`	Credit Limit	`x_credit_limit`	currency	Custom	Optional
`account`	Health Score	`x_health_score`	percent	Custom	Optional
`account`	Primary Warehouse	`x_primary_warehouse`	lookup	Custom	→ warehouses
`account`	Billing Profile	`x_billing_profile`	lookup	Custom	→ x_billing_profile
`account`	Active	`x_active`	checkbox	Custom	Optional
`account`	Created By	`createdbyid`	lookup	Standard	System managed · → user
`account`	Last Modified	`lastmodifieddate`	datetime	Standard	System managed
`contact`	Full Name	`name`	text	Standard	Required · System managed
`contact`	Account	`accountid`	lookup	Standard	→ account
`contact`	Email	`email`	email	Standard	Unique
`contact`	Title	`title`	text	Standard	Optional
`contact`	Reports To	`reportstoid`	lookup	Standard	→ contact
`opportunity`	Opportunity Name	`name`	text	Standard	Required · System managed
`opportunity`	Account	`accountid`	lookup	Standard	→ account
`opportunity`	Stage	`stagename`	picklist	Standard	Required
`opportunity`	Amount	`amount`	currency	Standard	Optional
`opportunity`	Close Date	`closedate`	date	Standard	Required
`case`	Case Number	`casenumber`	autonumber	Standard	Unique · System managed
`case`	Account	`accountid`	lookup	Standard	→ account
`case`	Contact	`contactid`	lookup	Standard	→ contact
`case`	Priority	`priority`	picklist	Standard	Optional
`invoices`	Invoice Number	`Name`	text	Standard	Required · Unique
`invoices`	Account	`account`	master detail	Standard	→ Account
`invoices`	Total	`x_total`	currency	Custom	Optional
`invoices`	Due Date	`x_due_date`	date	Custom	Optional
`invoice_items`	Invoice	`invoices`	master detail	Standard	→ invoices
`invoice_items`	Quantity	`x_quantity`	number	Custom	Optional
`shipments`	Account	`account`	lookup	Standard	→ Account
`shipments`	Origin Warehouse	`x_origin`	lookup	Custom	→ warehouses
`x_onboarding_project`	Account	`account`	master detail	Imported	→ Account
`x_onboarding_project`	Team Members	`x_team_members`	lookup	Custom	→ employee
`customers`	ID	`id`	text	Imported	Required · Unique · System managed
`customers`	Name	`name`	text	Imported	Required
`customers`	Status	`status`	picklist	Imported	Optional
`customers`	Created at	`created_at`	datetime	Imported	System managed
`customers`	CRM owner	`x_crm_owner_id`	lookup	Custom	→ User
`customers`	Renewal date	`x_renewal_date`	date	Custom	Optional
`orders`	ID	`id`	text	Imported	Required · Unique · System managed
`orders`	Customer ID	`customer_id`	lookup	Imported	→ customers
`orders`	Amount	`amount`	currency	Imported	Optional
`orders`	Status	`status`	picklist	Imported	Optional
`orders`	Created at	`created_at`	datetime	Imported	System managed
`x_projects`	ID	`id`	text	Standard	Required · Unique · System managed
`x_projects`	Name	`name`	text	Custom	Required
`x_projects`	Customer ID	`x_customer_id`	lookup	Custom	→ customers
`x_projects`	Status	`x_status`	picklist	Custom	Optional
`x_sites`	Name	`name`	text	Custom	Required
`x_sites`	Owner	`owner_id`	lookup	Standard	System managed
`x_sites`	Created	`created_at`	datetime	Standard	System managed
`x_sites`	Last modified	`updated_at`	datetime	Standard	System managed
`x_risks`	Name	`name`	text	Custom	Required
`x_risks`	Owner	`owner_id`	lookup	Standard	System managed
`x_risks`	Created	`created_at`	datetime	Standard	System managed
`x_risks`	Last modified	`updated_at`	datetime	Standard	System managed
`note`	ID	`id`	text	Standard	Required · Unique · System managed
`note`	Body	`body`	textarea	Standard	Required
`note`	Record ID	`record_id`	text	Standard	Optional
`note`	Created at	`created_at`	datetime	Standard	System managed

Supported data types

Types currently recognized by the metadata model.

textSingle-line text

textareaMulti-line text

numberNumeric value

currencyMoney value

percentPercentage

dateCalendar date

datetimeDate and time

checkboxTrue or false

picklistValue from a fixed list

emailEmail address

phonePhone number

urlWeb address

formulaCalculated, read-only value

autonumberSystem-generated identifier

lookupLink to a record in another table

master_detailRequired parent-child relationship

JavaScript execution model

Customer scripts use plain JavaScript. Java is not required for classes, business logic, database operations, processes, or background jobs.

Synchronous

Wait for a result

Use for short validation, calculation, and record operations that must finish before the process continues.

scripts.run("validate-order", input)

Asynchronous

Run in the background

Use when the caller should receive a job ID immediately and check the result later.

scripts.runAsync("recalculate", input)

Queueable

Control when work runs

Use durable queues for delayed or high-volume work with priority, concurrency, retries, and scheduling.

queue.enqueue("import-accounts", input)

Capability	JavaScript support	Guidance
Reusable classes and functions	Supported	Publish a stable `execute(input, context)` entry point so processes can invoke versioned code.
Records and metadata	Supported	Use controlled APIs such as `crm.records` and `crm.metadata`; direct credentials are never exposed.
Process and scheduled execution	Supported	The platform runs JavaScript server-side with permissions, logs, timeouts, retries, and idempotency controls.
Page components	Supported	Use the platform's JavaScript `page` helpers without requiring React or TypeScript knowledge.

When would Java be needed?

None of the platform capabilities above inherently require Java. Use a separate Java service only when an external requirement depends on the JVM—for example, an existing Java-only library, a vendor SDK with no JavaScript or HTTP interface, a legacy Java application that must host the logic, or an organization that mandates JVM deployment. Connect that service through an authenticated API or event; do not mix Java into customer scripts.

Behavior rules

Labels are customer-facing and editable; API names are integration contracts and should remain stable after creation.
Imported metadata preserves source names. Custom fields added to imported tables use the x_ prefix.
Relationship fields store both a relationship type and the target object API name.
Required, unique, and system-managed flags are independent and can be combined.
Every tenant-owned metadata row includes tenant_id for tenant isolation.

All data access passes through the platform

FirstHour CRM / integrations→FirstHour Data API→FirstHour Data Platform→Supabase

Public contract: https://api.example.com/v1 · OpenAPI document: https://api.example.com/openapi · JavaScript package: @firsthour/sdk

How an external integration connects

1
Register an API Client
In Setup → API Clients, enter a recognizable name such as ERP Production and approve only the scopes it needs.
2
Store the credentials securely
FirstHour issues a client_id and one-time client_secret. The secret belongs in the integration's server-side secret manager, never browser code.
3
Request an access token
Send the credentials with grant_type=client_credentials to POST https://api.example.com/oauth/token. The platform returns a short-lived, scoped token.
4
Call the Data API
Send Authorization: Bearer <access_token> to routes such as GET /v1/records/account. Clients never connect directly to Supabase.

How regional Production and Sandbox data flows

Column

Purpose

Example

id

Private PostgreSQL UUID used only for internal joins; never returned by the API

Hidden

public_id

Immutable customer-facing ULID returned as id

7BC1DED566A8753AA018DB2538

tenant_id

Tenant isolation boundary

t_halden

environment_id

Production or sandbox placement

env_halden_prod

object_api_name

Logical object discriminator

account or contact

data

Field values keyed by field API name

{ "name": "…" }

external_id

Optional integration identifier

demo-account-northstar

version

Optimistic concurrency version

1

deleted_at

Soft-delete marker; active queries require null

null

object_api_name

public_id (API id)

external_id

tenant_id

environment_id

account

7BC1DED566A8753AA018DB2538

demo-account-northstar

t_halden

env_halden_prod

contact

07EED42762D0EE644A8CD20EF9

demo-account-northstar-contact-1

t_halden

env_halden_prod

Customer choice

Provider region

Production project

Sandbox project

Placement note

United States

us-east-1

fh-us-east-1-prod-01

fh-us-east-1-sandbox-01

Current US East project becomes the first Production cell.

United Kingdom

eu-west-2

fh-eu-west-2-prod-01

fh-eu-west-2-sandbox-01

London is a separate residency option, not EU residency.

European Union

eu-central-1

fh-eu-central-1-prod-01

fh-eu-central-1-sandbox-01

Frankfurt provides the initial EU-member location.

India

ap-south-1

fh-ap-south-1-prod-01

fh-ap-south-1-sandbox-01

Mumbai provides the initial India residency option.

Australia

ap-southeast-2

fh-ap-southeast-2-prod-01

fh-ap-southeast-2-sandbox-01

Sydney provides the initial Australia residency option.

Future market

Provider region

Production project

Sandbox project

US West (Oregon)

us-west-2

fh-us-west-2-prod-01

fh-us-west-2-sandbox-01

US West (Northern California)

us-west-1

fh-us-west-1-prod-01

fh-us-west-1-sandbox-01

US East (Ohio)

us-east-2

fh-us-east-2-prod-01

fh-us-east-2-sandbox-01

Canada

ca-central-1

fh-ca-central-1-prod-01

fh-ca-central-1-sandbox-01

Ireland

eu-west-1

fh-eu-west-1-prod-01

fh-eu-west-1-sandbox-01

France

eu-west-3

fh-eu-west-3-prod-01

fh-eu-west-3-sandbox-01

Switzerland

eu-central-2

fh-eu-central-2-prod-01

fh-eu-central-2-sandbox-01

Sweden

eu-north-1

fh-eu-north-1-prod-01

fh-eu-north-1-sandbox-01

Singapore

ap-southeast-1

fh-ap-southeast-1-prod-01

fh-ap-southeast-1-sandbox-01

Japan

ap-northeast-1

fh-ap-northeast-1-prod-01

fh-ap-northeast-1-sandbox-01

South Korea

ap-northeast-2

fh-ap-northeast-2-prod-01

fh-ap-northeast-2-sandbox-01

South America (Brazil)

sa-east-1

fh-sa-east-1-prod-01

fh-sa-east-1-sandbox-01

Kind

Rule

Examples

Standard

Platform-owned object and field names use stable lowercase identifiers.

account ownerid

Custom

Custom table and field API names use snake_case with the x_ prefix.

x_projects x_health_score

Imported

Keep the connected source table and column identifiers; they are not renamed.

orders customer_id

System fields

Managed by the platform or source. They can be required or unique and should not be repurposed.

id CreatedById created_at

Concept

Term

Entity

Table

Row

Record

Column

Field

Relationship

Link

Owned relationship

Parent-child

Validation rule

Check

Required

Required (toggle label)

Dropdown list

Choice list

Page layout

View

Table

API name

Kind

Source

Fields

Account

account

Standard

native

Contact

contact

Standard

native

Opportunity

opportunity

Standard

native

Case

case

Standard

native

Invoice

invoices

Imported

billing.invoices

Invoice Line

invoice_items

Imported

billing.invoice_lines

Shipment

shipments

Imported

public.shipments

Warehouse

warehouses

Imported

import

Onboarding Project

x_onboarding_project

Custom

native

Employee

employees

Imported

public.employees

Customer

customers

Imported

public.customers

Order

orders

Imported

public.orders

Order item

order_items

Imported

public.order_items

Product

products

Imported

public.products

Subscription

subscriptions

Imported

public.subscriptions

Project

x_projects

Custom

native

Site

x_sites

Custom

native

Risk

x_risks

Custom

native

Note

note

Standard

native

Table

Field label

API name

Data type

Origin

Checks

account

Account Name

name

text

Standard

Required · System managed

account

Account Number

accountnumber

autonumber

Standard

Unique · System managed

account

Account Owner

ownerid

lookup

Standard

Required · System managed · → user

account

Parent Account

parentid

lookup

Standard

→ account

account

Type

type

picklist

Standard

Optional

account

Industry

industry

picklist

Standard

Optional

account

Annual Revenue

annualrevenue

currency

Standard

Optional

account

Employees

numberofemployees

number

Standard

Optional

account

Phone

phone

phone

Standard

Optional

account

Website

website

url

Standard

Optional

account

Billing Street

billingstreet

textarea

Standard

Optional

account

Billing City

billingcity

text

Standard

Optional

account

Billing Country

billingcountry

picklist

Standard

Optional

account

Shipping City

shippingcity

text

Standard

Optional

account

Shipping Country

shippingcountry

picklist

Standard

Optional

account

Description

description

textarea

Standard

Optional

account

Customer Since

x_customer_since

date

Custom

Optional

account

Credit Limit

x_credit_limit

currency

Custom

Optional

account

Health Score

x_health_score

percent

Custom

Optional

account

Primary Warehouse

x_primary_warehouse

lookup

Custom

→ warehouses

account

Billing Profile

x_billing_profile

lookup

Custom

→ x_billing_profile

account

Active

x_active

checkbox

Custom

Optional

account

Created By

createdbyid

lookup

Standard

System managed · → user

account

Last Modified

lastmodifieddate

datetime

Standard

System managed

contact

Full Name

name

text

Standard

Required · System managed

contact

Account

accountid

lookup

Standard

→ account

contact

email

Standard

Unique

contact

Title

title

text

Standard

Optional

contact

Reports To

reportstoid

lookup

Standard

→ contact

opportunity

Opportunity Name

name

text

Standard

Required · System managed

opportunity

Account

accountid

lookup

Standard

→ account

opportunity

Stage

stagename

picklist

Standard

Required

opportunity

Amount

amount

currency

Standard

Optional

opportunity

Close Date

closedate

date

Standard

Required

case

Case Number

casenumber

autonumber

Standard

Unique · System managed

case

Account

accountid

lookup

Standard

→ account

case

Contact

contactid

lookup

Standard

→ contact

case

Priority

priority

picklist

Standard

Optional

invoices

Invoice Number

Name

text

Standard

Required · Unique

invoices

Account

account

master detail

Standard

→ Account

invoices

Total

x_total

currency

Custom

Optional

invoices

Due Date

x_due_date

date

Custom

Optional

invoice_items

Invoice

invoices

master detail

Standard

→ invoices

invoice_items

Quantity

x_quantity

number

Custom

Optional

shipments

Account

account

lookup

Standard

→ Account

shipments

Origin Warehouse

x_origin

lookup

Custom

→ warehouses

x_onboarding_project

Account

account

master detail

Imported

→ Account

x_onboarding_project

Team Members

x_team_members

lookup

Custom

→ employee

customers

id

text

Imported

Required · Unique · System managed

customers

Name

name

text

Imported

Required

customers

Status

status

picklist

Imported

Optional

customers

Created at

created_at

datetime

Imported

System managed

customers

CRM owner

x_crm_owner_id

lookup

Custom

→ User

customers

Renewal date

x_renewal_date

date

Custom

Optional

orders

id

text

Imported

Required · Unique · System managed

orders

Customer ID

customer_id

lookup

Imported

→ customers

orders

Amount

amount

currency

Imported

Optional

orders

Status

status

picklist

Imported

Optional

orders

Created at

created_at

datetime

Imported

System managed

x_projects

id

text

Standard

Required · Unique · System managed

x_projects

Name

name

text

Custom

Required

x_projects

Customer ID

x_customer_id

lookup

Custom

→ customers

x_projects

Status

x_status

picklist

Custom

Optional

x_sites

Name

name

text

Custom

Required

x_sites

Owner

owner_id

lookup

Standard

System managed

x_sites

Created

created_at

datetime

Standard

System managed

x_sites

Last modified

updated_at

datetime

Standard

System managed

x_risks

Name

name

text

Custom

Required

x_risks

Owner

owner_id

lookup

Standard

System managed

x_risks

Created

created_at

datetime

Standard

System managed

x_risks

Last modified

updated_at

datetime

Standard

System managed

note

id

text

Standard

Required · Unique · System managed

note

Body

body

textarea

Standard

Required

note

Record ID

record_id

text

Standard

Optional

note

Created at

created_at

datetime

Standard

System managed

Capability

JavaScript support

Guidance

Reusable classes and functions

Supported

Publish a stable execute(input, context) entry point so processes can invoke versioned code.

Records and metadata

Supported

Use controlled APIs such as crm.records and crm.metadata; direct credentials are never exposed.

Process and scheduled execution

Supported

The platform runs JavaScript server-side with permissions, logs, timeouts, retries, and idempotency controls.

Page components

Supported

Use the platform's JavaScript page helpers without requiring React or TypeScript knowledge.

Behavior rules

Labels are customer-facing and editable; API names are integration contracts and should remain stable after creation.

Imported metadata preserves source names. Custom fields added to imported tables use the x_ prefix.

Relationship fields store both a relationship type and the target object API name.

Required, unique, and system-managed flags are independent and can be combined.

Every tenant-owned metadata row includes tenant_id for tenant isolation.