Inviting Collaborators

Once your site is set up with page types and blocks, it’s time to hand it off to content editors. This guide shows you how to invite collaborators, manage permissions, and ensure a smooth handoff.

The Collaboration Model

Pala enables clean separation between developers and editors:

Developers control structure, design, and available options
Editors manage content, create pages, and publish
Both work independently without breaking each other’s work

The goal: Mutual autonomy. Developers can update structure anytime, and editors can manage content without waiting for developers.

Open site settings

Navigate to your site and click “Settings” in the sidebar.

Go to Team section

Click on “Team” or “Collaborators” to see current team members.

Click Invite

Click the “Invite Collaborator” button.

Enter email and role

Fill in the invitation form:

Email: The collaborator’s email address
Role: Choose their permission level (Content Editor or Developer)
Message (optional): Add a personal note to the invitation

Include a message explaining what you want them to do: “I’ve set up the blog structure. You can start creating posts!”

Send invitation

Click “Send Invitation”. The collaborator receives an email with a link to accept.

The invitation is sent! Your collaborator will receive an email with instructions to get started.

Roles and Permissions

Pala has two primary roles:

Content Editor

What they can do:

Create, edit, and delete pages
Add and remove blocks (from available options)
Edit block content
Upload images and media
Publish and unpublish pages
View site analytics (if enabled)

What they can’t do:

Modify page types
Change available blocks
Edit component code
Change site settings
Invite other collaborators
Access developer tools

Use the Content Editor role for content managers, copywriters, and anyone who only needs to manage pages.

Developer

What they can do:

Everything Content Editors can do, plus:
Create and modify page types
Add and configure blocks
Change site settings
Invite collaborators
Manage team members
Access developer tools
Deploy and manage hosting

Developer access gives full control over the site, including the ability to break things. Only give Developer access to trusted developers or technical staff.

Choosing the Right Role

Use Content Editor role for:

Content writers
Marketing team members
Client staff managing their own content
Anyone who only needs to create/edit pages

Use Developer role for:

Developers
Technical leads
Agency staff managing client sites
Anyone who needs to modify structure

The Handoff Process

Follow these steps for a smooth developer-to-editor handoff:

1. Before Inviting

Prepare the site for editors:

Set up page types

Create all necessary page types with:

Available blocks configured
Page fields defined
Header and footer slots set up
Helpful field labels and descriptions

Create example pages

Build 1-2 example pages for each page type:

Shows editors what’s possible
Demonstrates best practices
Serves as templates to duplicate

Editors often duplicate example pages instead of starting from scratch. Make them good!

Test the editor experience

Put yourself in the editor’s shoes:

Can you build complete pages with available blocks?
Are field labels clear?
Is anything confusing or missing?
Do example pages look good?

Prepare documentation

Create a quick guide covering:

How to create each page type
Which blocks to use for what
Any specific guidelines (brand, tone, etc.)
Common tasks (publishing, adding images, etc.)

You can share the Using the Editor guide from these docs as a starting point.

2. During the Invitation

Make the invitation clear and helpful:

Good invitation message:“Hey Sarah! I’ve set up the blog structure for our site. You can start creating blog posts right away. I’ve added a few examples to show you what’s possible. Check out the ‘Blog Post’ page type when creating new pages. Let me know if you need anything added!”Bad invitation message: “You’re invited to edit the site.”

3. After They Accept

Follow up to ensure they’re successful:

Schedule a quick walkthrough

Spend 15-30 minutes showing them:

How to create their first page
Where to find example pages
How to add and edit blocks
How to publish when ready

Be available for questions

The first few days, be responsive to questions:

Answer quickly to avoid blockers
Note repeated questions (might indicate unclear design)
Offer to add features if they’re struggling

Gather feedback

After they’ve created a few pages, ask:

What was confusing?
What blocks are you wishing you had?
What feels limiting?
What’s working well?

Use this feedback to improve page types and blocks.

Managing Team Members

Viewing Team Members

To see all collaborators on a site:

Open site settings
Go to Team section
View list of all members with their roles

Changing Roles

To change a collaborator’s role:

Find the team member in the list
Click on their role dropdown
Select the new role (Content Editor or Developer)
Confirm the change

Changing someone from Developer to Content Editor immediately removes their access to developer tools and settings.

Removing Collaborators

To remove someone from the site:

Find them in the team list
Click the remove/delete icon
Confirm removal

Removed collaborators lose all access to the site immediately. Their created content remains on the site.

Multi-Site Access

If you manage multiple sites, you can invite the same person to different sites:

Same role across sites: Invite them with the same email to each site
Different roles per site: They can be a Content Editor on one site and Developer on another
Separate permissions: Access to one site doesn’t grant access to others

This is useful for agencies managing client sites. You might be a Developer on all sites, but clients are Content Editors on only their own site.

Best Practices

1. Start with Content Editor Role

When in doubt, start with the Content Editor role:

Gives enough access for content work
Protects site structure from accidents
Can always upgrade to Developer later if needed

2. Create Clear Examples

Good example pages teach without documentation:

Show all available blocks in use
Demonstrate best practices
Include helpful placeholder content
Make them easy to duplicate

3. Provide Context in Invitations

A good invitation message includes:

What you want them to do
Where to start (which page types, examples)
Who to ask if they have questions
Any relevant guidelines or docs

4. Set Expectations Early

Be clear about:

What they can change: Content, images, page structure (within page types)
What they can’t change: Design, colors, fonts, available blocks
How to request changes: Who to ask for new features or blocks

5. Iterate Based on Usage

Watch how editors use the site:

What do they struggle with?
What do they ask for repeatedly?
What blocks go unused?
What workarounds are they creating?

Use this to improve page types and add helpful blocks.

Common Scenarios

Client Handoff

Scenario: Building a site for a client who will manage their own content Best approach:

Build and configure everything as Developer
Create comprehensive examples for each page type
Invite client as Content Editor
Walk them through the basics (15-30 min)
Share documentation link
Be available for first few days
Schedule check-in after 1-2 weeks

Team Collaboration

Scenario: Multiple content writers on your team Best approach:

Invite all as Content Editors
Create clear examples for each content type
Establish content guidelines (tone, style, formatting)
Set up review process if needed
Use page status/drafts for collaboration

Agency Multi-Site

Scenario: Managing many client sites Best approach:

You’re Developer on all sites
Each client is Content Editor on their own site only
Use consistent page type patterns across sites
Create a reusable library of blocks
Document common processes for efficiency

Developer Team

Scenario: Multiple developers working on one site Best approach:

All developers have Developer role
Communicate changes to page types/structure
Test thoroughly before deploying
Use version control for code
Coordinate on block library changes

Troubleshooting

Invitation Not Received

Problem: Collaborator didn’t get the email Solutions:

Check spam/junk folder
Verify email address is correct
Resend the invitation
Check if email service is blocking

Content Editor Can’t Find Blocks

Problem: “I need X block but I don’t see it” Solution:

Add the block to the page type’s available blocks
Or explain which available block to use instead

Content Editor Wants to Change Design

Problem: “Can I change the colors/fonts?” Solution:

Explain that design is controlled by you (developer)
Offer to make the change for them
If it’s a common request, consider adding it as a configurable option (site field or block field)

Too Many Requests

Problem: Content editor constantly asking for changes Solutions:

Review their requests for patterns
Add commonly requested blocks to page types
Make fields more flexible if appropriate
Set expectations about what’s configurable vs. fixed

Accidental Deletion

Problem: Content editor deleted something important Solution:

Check if there’s a backup or revision history (if enabled)
Recreate from example page if available
For future: educate on being careful with deletions
Consider more restrictive permissions if repeated issue

Next Steps

Setting Up Page Types

Configure page types before inviting collaborators.

Using the Editor

Share this guide with your content editors.

The best collaborations start with clear communication. Explain what you’ve built, what editors can do, and how to ask for help. A good 15-minute walkthrough saves hours of confusion later.

Getting Started

Building Sites

Collaboration

Content Management

Dashboard

Reference

​The Collaboration Model