> For the complete documentation index, see [llms.txt](https://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://guardian.hedera.com/docs/develop/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).
* **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.
* **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.
* **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.
* **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.
* **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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://guardian.hedera.com/docs/develop/guardian/standard-registry/schemas/best-practices-to-implement-schema/excel-first-design.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.