Configuration tables#

Configuration tables are how Business Language represents policy that changes by tenant, company, country, process, or time.

For package, workspace, and compiler/runtime configuration syntax, see Configuration declarations.

For the full end-to-end shape, see Configuration resolver patterns.

When to use configuration#

Use configuration tables for:

• Status transitions.
• Approval routing.
• Thresholds and tolerances.
• Reason codes.
• Workflow outcomes.
• Posting controls and locks.

Resolution shape#

A configuration resolver should filter by scope, require active rows, handle validity dates when present, and fail closed when resolution is missing or ambiguous.

private function resolve_posting_policy(
  company_code_param: CompanyCode,
  document_type_param: DocumentType,
  posting_date_param: date
): PostingPolicy {
  select var policy: PostingPolicy
    where PostingPolicy.company_code = company_code_param
      and PostingPolicy.document_type = document_type_param
      and PostingPolicy.active = true
      and PostingPolicy.valid_from <= posting_date_param
      and (
        PostingPolicy.valid_to is null
        || PostingPolicy.valid_to >= posting_date_param
      );

  if (policy is null) {
    raise message posting_policy_required(company_code_param, document_type_param) with {
      company_code: company_code_param;
      document_type: document_type_param;
    };
  }

  return policy;
}

Enum boundary#

Use enums for true invariants only. If a value list is owned by an implementation team or customer administrator, model it as table data.