As an administrator in CurryCMS, you design the architecture that authors use to create curriculum content. This overview explains your role, responsibilities, and how to get started.
What is an Administrator?
Administrators are team members who design and manage the platform's structure and configuration. You create the templates (structures) that define how curriculum content can be organized, and you manage team access.
Your focus: Platform architecture and team management, not daily content authoring.
What Admins Can Do
As an admin, you have full platform access:
Structure Management:
- ✓ Create, edit, and delete structures
- ✓ Clone structures for variations
- ✓ Create structure variants
Schema Configuration:
- ✓ Create and configure node types
- ✓ Define allowed children (hierarchy rules)
- ✓ Create and manage attribute bundles
- ✓ Apply bundles to node types
Content Management:
- ✓ Create, edit, and delete any curriculum
- ✓ Work with all content nodes
- ✓ Manage standards alignment
Team Management:
- ✓ Invite and remove team members
- ✓ Assign and change roles
- ✓ View team activity
Account Administration:
- ✓ Update account settings
- ✓ Manage integrations
- ✓ Configure account preferences
What admins cannot do (owner only):
- ❌ Delete the entire account
- ❌ Manage billing and subscription
- ❌ Transfer account ownership
Core Admin Concepts
1. Structures vs. Curricula
The fundamental distinction in CurryCMS:
Structure (Template)
- Defines what CAN exist
- Created by administrators
- Reusable across many curricula
- Example: "K-12 Mathematics Structure"
Curriculum (Instance)
- Contains actual content
- Created by authors
- Based on one structure
- Example: "Grade 3 Math - 2025 Edition"
Analogy:
- Structure = Blueprint for a house
- Curriculum = Actual house built from that blueprint
Your role: Design blueprints (structures) that authors use to build houses (curricula).
2. Node Types
Node types define the kinds of content that can exist in a structure.
Common node types:
- Course (root level)
- Unit (mid-level container)
- Lesson (instructional unit)
- Activity (learning engagement)
- Assessment (evaluation)
Each node type defines:
- Display name (what authors see)
- System name (API identifier, immutable)
- Icon (visual identifier)
- Whether it can be a root (top-level)
- Which types it can contain (allowed children)
- Which attributes it has
Example node type definition:
Node Type: Lesson
├── Display Name: "Lesson"
├── System Name: "lesson"
├── Icon: 📖
├── Is Root: No
├── Allowed Children: [Activity, Assessment]
└── Attributes (via bundles):
├── Basic Info Bundle: Title, Description
├── Timing Bundle: Duration, Pacing Notes
└── Standards Alignment Bundle
3. Attribute Bundles
Attribute bundles are reusable collections of attributes that you apply to node types.
Why use bundles?
- Define once, reuse across multiple types
- Change bundle → all types using it update automatically
- Ensures consistency across your structure
Example bundles:
"Basic Info" bundle:
- Title (string, required)
- Description (text, optional)
- Thumbnail (url, optional)
Applied to: All node types
"Timing" bundle:
- Duration (integer, minutes)
- Pacing Notes (text)
Applied to: Lesson, Activity
Benefit: Change "Basic Info" to add "Author" field → all node types get it instantly.
4. Allowed Children (Hierarchy Rules)
Allowed children rules define which node types can contain which other types.
Example hierarchy:
```
Course
└── allowed children: [Unit]
Unit
└── allowed children: [Lesson, Assessment]
Lesson
└── allowed children: [Activity, Assessment]
Activity
└── allowed children:
```
Result: Authors can only create valid structures. The system prevents:
- Adding a Unit directly inside a Lesson
- Adding a Course inside a Unit
- Creating hierarchies that violate your design
Your job: Design hierarchy rules that match your curriculum organization.
5. Structure Variants
Structure variants inherit from a parent structure but can add specialized node types or attributes.
Example:
- Parent: K-12 Math Structure (Course → Unit → Lesson → Activity)
- Variant: K-12 Science Structure (adds "Lab Activity" type for science-specific content)
When to use:
- Regional requirements need additional types
- Subject-specific extensions
- Maintaining compatibility with base structure
Key behavior:
- Inherits all parent node types
- Can add new types
- Cannot remove inherited types
Your Admin Workspace
Schema Menu
Access structure management tools:
Schema → Structures
- View all structures
- Create new structures
- Edit existing structures
- Clone or create variants
Schema → Node Types
- View all node types across structures
- Access from structure detail pages
Schema → Attribute Bundles
- Create and manage bundles
- View bundle usage across types
Content Menu
Same access as authors, but with full permissions:
Content → Curricula
- View all curricula (not just your own)
- Edit any curriculum
- Delete any curriculum
- Manage variants
Standards → Browse
- View all standards libraries
- Manage standards data (if permitted)
Account Settings
Settings → Team
- View all team members
- Invite new members
- Change roles
- Remove members
Settings → Account
- Update account name
- Configure integrations
- Manage preferences
Common Admin Workflows
Creating Your First Structure
Step 1: Plan
- List the content types you need (Course, Unit, Lesson, etc.)
- Sketch the hierarchy (what contains what)
- Identify attributes for each type
Step 2: Create Structure
1. Navigate to Schema → Structures
2. Click Create Structure
3. Enter name and description
4. Click Create
Step 3: Add Node Types
1. In Structure Builder, click Add Node Type
2. Fill in display name, system name, icon
3. Mark as root if appropriate
4. Save the node type
5. Repeat for all types
Step 4: Configure Hierarchy
1. Select a node type
2. In the "Allowed Children" section, check which types it can contain
3. Save (autosaves)
4. Repeat for all parent types
Step 5: Add Attributes (via Bundles)
1. Navigate to Schema → Attribute Bundles
2. Create bundles (e.g., "Basic Info", "Timing")
3. Add attributes to each bundle
4. Return to Structure Builder
5. Apply bundles to node types
See Designing Structures for detailed steps.
Creating an Attribute Bundle
- Navigate to Schema → Attribute Bundles
- Click Create Bundle
- Enter name and description
- Click Create
- Click Add Attribute
- Configure attribute (name, type, required, etc.)
- Save attribute
- Repeat to add more attributes
See Attribute Bundles for detailed steps.
Applying a Bundle to Node Types
- Open Schema → Structures
- Select your structure
- Click on a node type
- Scroll to "Attribute Bundles" section
- Select the bundle to apply
- Save
Result: All attributes from that bundle are now available on content nodes of that type.
Inviting Team Members
- Navigate to Settings → Team
- Click Invite Member
- Enter email address
- Select role (Admin, Designer, Editor, Author, Viewer)
- Add optional message
- Click Send Invitation
See Team Management for detailed steps.
Admin Best Practices
Design Philosophy
Start simple, grow as needed:
- Begin with 3-4 essential node types
- Add bundles for core attributes only
- Expand based on real usage, not theoretical needs
Mirror reality, not ideals:
- Structure should match how content actually exists
- Don't force content into abstract organizational patterns
- Test with real content before rollout
Plan for flexibility:
- Leave room for future node types
- Use bundles for attributes (easier to modify)
- Consider variants for regional/subject differences
Planning Structures
Before creating:
1. Interview content authors about their needs
2. Examine existing content to understand organization
3. Sketch hierarchy on paper or whiteboard
4. List attributes for each node type
5. Identify reusable attribute patterns (bundle candidates)
Questions to answer:
- What is the smallest unit of content? (Activity, Page, Slide)
- What is the largest container? (Course, Program, Curriculum)
- How many levels of nesting are needed?
- Which attributes apply to all types vs. specific types?
- Do different subjects need different structures?
Naming Conventions
Structure names:
- ✅ "K-12 Mathematics Structure"
- ✅ "Course-Unit-Lesson Template"
- ❌ "Structure 1", "Math Thing"
Node type names:
- ✅ "Course", "Unit", "Lesson", "Activity"
- ✅ "Learning Module", "Assessment"
- ❌ "Type1", "Container", "Content"
System names (immutable):
- ✅ "course", "learning_module", "formative_assessment"
- ❌ "c", "lm", "fa" (too abbreviated)
Bundle names:
- ✅ "Basic Info", "Timing Details", "SEO Metadata"
- ❌ "Bundle A", "Stuff", "Fields"
Testing Before Rollout
Before authors use your structure:
1. Create a test curriculum
2. Add content for all node types
3. Fill in all attributes
4. Verify hierarchy rules work as expected
5. Check for missing attributes or awkward workflows
6. Iterate based on findings
Common discoveries during testing:
- Missing required attributes (e.g., forgot "Author" field)
- Hierarchy too rigid (need more flexibility)
- Attribute ordering confusing for authors
- Missing node type for edge cases
Documentation
Document your design decisions:
- Why each node type exists
- Intended use for each type
- What attributes are required and why
- Hierarchy logic and constraints
- Examples of completed content
Share with team:
- Structure documentation
- Author guidelines
- Quick reference cards
Maintenance
Regular reviews:
- Monthly: Check for requests from authors
- Quarterly: Review usage patterns
- Annually: Major structure review and updates
When to modify structures:
- Authors consistently request missing attributes
- Hierarchy rules too restrictive for real content
- New content types emerge
When NOT to modify:
- One-off requests (may be content organization issue)
- Theoretical use cases that don't exist yet
- Changes that would break existing content
Role-Based Views
Admin vs. Designer
Both roles can manage structures, but:
Admin:
- Invites and manages team
- Full account access
- Can do everything Designer can do + more
Designer:
- Focused on structure design only
- Cannot manage team or account
- Ideal for instructional designers
Recommendation: Use Designer role for people focused solely on curriculum architecture.
Admin vs. Editor vs. Author
Content permissions differ:
Admin:
- Edits any curriculum
- Deletes any content
- Full access
Editor:
- Edits any curriculum
- Cannot manage structures or team
- Focused on content quality
Author:
- Edits own curricula only
- Cannot access structures
- Focused on content creation
Strategy: Most team members should be Authors. Use Editor sparingly for content review roles.
Getting Help
Documentation
Core admin guides:
- Designing Structures - Complete structure design guide
- Managing Node Types - Node type configuration
- Attribute Bundles - Bundle creation and management
- Team Management - User and role management
Additional resources:
- Glossary - Key terminology
- Getting Started - Platform overview
- Author Overview - Help authors understand their role
Common Admin Questions
"How many structures should I create?"
Typically 1-3 for most organizations. Create one per distinct content domain (Math, Science, ELA) or one universal structure for all content.
"Can I change a structure after curricula are using it?"
Yes, but carefully. Adding node types and attributes is safe. Removing them affects existing content. Test changes on cloned structures first.
"Should I create one structure or multiple?"
One structure if organization is similar across subjects. Multiple if subjects have fundamentally different hierarchies.
"What's the difference between structure variants and cloning?"
Variants maintain inheritance (changes flow from parent). Clones are independent copies with no connection.
"Can I merge two structures?"
No automatic merge. You must create a new structure manually and migrate content.
Next Steps
Ready to start building your platform?
- Designing Structures - Create your first structure
- Managing Node Types - Configure node types
- Attribute Bundles - Set up attribute bundles
- Team Management - Invite your team
Related Documentation:
- Designing Structures - Comprehensive structure design guide
- Managing Node Types - Node type configuration
- Attribute Bundles - Bundle setup and management
- Team Management - Team and role administration
- Glossary - Key terms and concepts