> For the complete documentation index, see [llms.txt](https://dev.guardian.hedera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev.guardian.hedera.com/guardian/standard-registry/schemas/best-practices-to-implement-schema/excel-first-design.md).

# Excel-First Design

Detailed best practices for Excel-first design in building Hedera Guardian schemas focus on using structured Excel templates to define all necessary fields, data types, validation rules, and conditional logic clearly before importing into Guardian. This method improves collaboration, clarity, and iterative feedback especially for complex sustainability methodologies.

### Key Best Practices for Excel-First Design

* **Start with a Standard Header**\
  Use the first rows of the Excel sheet to define the schema identity and type, e.g.,

  * Row 1: Schema Name (e.g., "Project Description (Auto)")
  * Row 2: Schema Description
  * Row 3: Schema Type (e.g., "Verifiable Credentials")
  * Row 4: Column headings for schema field attributes (Required Field, Field Type, Parameter, Visibility, Description, Allow Multiple Answers, Test Value, Default Value, Suggest Value, Key).

  <figure><img src="/files/WirvzFdQQ40MA5HFQVKC" alt=""><figcaption></figcaption></figure>
* **Define Each Field with Clear Attributes**\
  For every schema field, specify:

  * Required (Yes/No)
  * Field Type (String, Number, Date, Enum, Boolean, Image, Auto-Calculate, Help Text, etc.)
  * Parameter or reference to enums/calculations if applicable
  * Visibility setting (TRUE/FALSE/Hidden) to control when fields appear
  * User-facing question (label text)
  * Allow multiple answers? (Yes/No)
  * Default or example value for user guidance.

  <figure><img src="/files/NrXBiZGPLJ4jEEIkFvK5" alt=""><figcaption></figcaption></figure>
* **Use a Shared Enum Tab for Controlled Vocabularies**\
  All enumerated types are defined in a single shared `Enums` tab with four columns: Schema name, Field name, Loaded to IPFS, Value. Group values by field, fill in Schema name, Field name, and Loaded to IPFS only on the first row of each group, leaving them blank for subsequent values.

<figure><img src="/files/F7cGkFqNlPrSdOMS6vD7" alt=""><figcaption></figcaption></figure>

* **Define Sub-Schemas Inline**\
  Fields of type `Sub-Schema` group nested child fields directly.
* **Implement Conditional Logic via Visibility Columns**\
  Use TRUE to keep fields always visible; use FALSE or "Hidden" to permanently hide fields (e.g., system-only or metadata fields); use a formula (EXACT, OR, AND) in the Visibility column for conditional visibility based on enum selections or workflow stage. This reduces user burden and aligns forms dynamically with project selections.

<figure><img src="/files/CxWHBidJNN0w3m11We2A" alt=""><figcaption></figcaption></figure>

* **Incorporate Advanced Field Types**\
  Include Auto-Calculate fields for computed values, Image/File Upload fields for supporting documents, and Help Text fields to provide contextual guidance inline.

<figure><img src="/files/0Ch59NWT6l4n27kSIobM" alt=""><figcaption></figcaption></figure>

* **Validation and Data Integrity**\
  Mark critical fields as required to enforce data capture. Choose proper data types for automatic Guardian validation (numbers, dates, boolean, urls). Use patterns or formulas as needed for more complex rules.
* **Field Key Management Post-Import**\
  After importing, rename default field keys in Guardian UI to meaningful, calculation-friendly names. This dramatically improves maintainability of formula/code logic referencing schema fields.
* **Collaborate Closely with Domain Experts**\
  Excel-first enables domain experts (e.g., carbon scientists) to review, comment, and iterate schema designs before committing to implementation.