Blueprint Pattern
Creating multiple related records atomically
Overview
The Blueprint Pattern allows you to create multiple related records in a single
atomic operation using Record.createAll(). This is essential when you need
to set up interconnected data structures where records reference each other.
Why Use Blueprints?
Without blueprints, creating related records requires multiple steps:
With blueprints, you declare everything in one operation:
Basic Syntax
The Reference Syntax
Use {{recordName}} syntax to reference another record being created in the same
blueprint. This is replaced with the actual ID after creation:
Organization Blueprint Example
This comprehensive example creates an organization with multiple teams and proper permission hierarchies:
Adding Items to a Blueprint Structure
Once you have the structure, you can add items:
Type Options
The type field accepts these values:
| Type | Description |
|---|---|
'KeyValueAttribute' | JSON document with CRDT support (KeyValue Record) |
'LongTextAttribute' | Large text with OT collaboration (LongText Record) |
'BlobAttribute' | Binary file storage (Blob Record) |
Error Handling
Blueprint creation is atomic - if any part fails, the entire operation fails:
If any fact in the blueprint fails authorization, the entire createAll()
operation will throw an error. Ensure all referenced terms are declared and
you have appropriate permissions.
Common Permission Patterns
Read-Only Access for a Team
Read-Write Access for a Team
Allow Team to Create Related Facts
Transfer Accountability to Organization
Allow Team to Manage Membership
Best Practices
-
Declare terms first - Always declare terms before creating blueprints that use them
-
Use meaningful names - Choose descriptive record names in the blueprint for clarity
-
Plan permissions carefully - Think through who needs what access before implementing
-
Keep blueprints focused - Create separate blueprints for distinct concepts rather than one massive blueprint
-
Document your blueprints - Complex blueprints benefit from comments explaining the permission model
-
Test permission flows - Verify that users at each level have exactly the access they need