Skip to main content

​
Three Permission Levels

When you share a process, you choose what level of access each person gets. The Business Process Framework uses three standard permission levels that control what people can do with your processes.
Think of permissions like levels of trust. View is “you can see it,” Comment is “you can give feedback,” and Edit is “you can change it.”

​
The Three Levels

View

Can see, can’t changeRead-only access to the process

Comment

Can see and suggestView access plus ability to add comments

Edit

Can change anythingFull access to modify the process

​
View Permission

View permission gives read-only access. People can see the process but can’t make any changes.

​
What You Can Do with View Permission

See Process Details

  • View all activities and their sequence
  • See RACI assignments
  • Read all documentation (SOPs, guides, blueprints)
  • View visual and swimlane diagrams
  • See forms and attachments
  • View KPIs and performance data
  • Follow process steps while working
  • Reference procedures during tasks
  • Print or export for personal use
  • Bookmark or favorite the process
  • Search within the process
  • Open the process whenever needed
  • View on any device (desktop, tablet, mobile)
  • See real-time updates made by others
  • Receive notifications about changes (if enabled)

​
What You CANNOT Do with View Permission

Cannot make any changes:
  • Can’t edit activities
  • Can’t update documentation
  • Can’t change RACI assignments
  • Can’t add or remove content
  • Can’t share with others
  • Can’t add comments or suggestions

​
Best For

Process Users

Team members who follow the process but don’t maintain it

New Employees

People learning the process who shouldn’t edit yet

Stakeholders

Managers or partners who need visibility but not control

Wide Distribution

Company-wide processes everyone needs to reference
Example: Share your customer support process with all support agents (View permission). They can reference procedures while handling tickets but can’t accidentally change the documented process.

​
Comment Permission

Comment permission includes everything View permission offers, plus the ability to add comments and suggestions.

​
What You Can Do with Comment Permission

Everything from View

All View permissions apply:
  • See all process details
  • Use as reference
  • Access from anywhere
  • Comment on activities
  • Comment on documentation
  • Ask questions about procedures
  • Tag other people in comments (@mentions)
  • Reply to existing comments
  • See all comment threads
  • Propose changes or improvements
  • Point out errors or unclear instructions
  • Share insights from experience
  • Recommend additional documentation
  • Suggest better RACI assignments
  • Participate in process improvement discussions
  • Provide feedback on updates
  • Vote or react to suggestions (if available)
  • See who else has access

​
What You CANNOT Do with Comment Permission

Cannot make direct changes:
  • Can’t edit the process structure
  • Can’t update activities or documentation
  • Can’t delete anything
  • Can’t share with others
  • Can’t accept or implement your own suggestions
However: Your comments and suggestions are visible to people with Edit permission, who can implement your ideas.

​
Best For

Subject Matter Experts

People with expertise who should provide input

Cross-Functional Partners

Teams that interact with the process

Process Reviewers

People auditing or improving processes

Collaborative Culture

Organizations that value input from all levels
Example: Share your sales process with the marketing team (Comment permission). They can’t edit the process, but they can suggest improvements to lead handoff procedures based on their experience.

​
Edit Permission

Edit permission gives full control. People can see, comment, and make changes to the process.

​
What You Can Do with Edit Permission

Everything from View and Comment

All View and Comment permissions apply:
  • See all process details
  • Add comments and suggestions
  • Collaborate with others
  • Add, edit, or delete activities
  • Create or modify categories
  • Reorder activities
  • Change activity properties
  • Update process descriptions
  • Create or edit SOPs
  • Write or modify guides
  • Create or update blueprints
  • Add or remove forms
  • Upload attachments
  • Assign RACI roles
  • Update role assignments
  • Remove assignments
  • Change who’s Responsible, Accountable, Consulted, or Informed
  • Share the process with others
  • Change permission levels
  • Remove people’s access
  • Generate share links
  • Manage organization-wide visibility
  • Create KPIs
  • Set targets and thresholds
  • Assign KPI ownership
  • Update KPI values
  • Delete KPIs

​
What You SHOULD NOT Do with Edit Permission

With great power comes great responsibility:
  • Don’t make significant changes without discussing with the team
  • Don’t delete content others created without agreement
  • Don’t change RACI assignments that were carefully planned
  • Don’t share processes with inappropriate people
  • Don’t make changes while others are actively editing (risk of conflicts)

​
Best For

Process Owners

Person responsible for maintaining the process

Team Leads

Managers who oversee the process area

Documentation Maintainers

Dedicated people updating documentation

Small Core Teams

Trusted group collaboratively maintaining processes
Example: Share your HR onboarding process with the HR Director and Senior HR Coordinator (Edit permission). They can update procedures as policies change without needing to ask permission for every edit.

​
Permission Comparison Table

​
Choosing the Right Permission Level

Ask yourself these questions:
1

Does this person perform activities in the process?

Yes: At minimum, give View permission so they can reference procedures.No: Consider if they need access at all.
2

Should this person help improve the process?

Yes: Give Comment permission so they can suggest improvements.No: View permission is sufficient.
3

Is this person responsible for maintaining documentation?

Yes: Give Edit permission so they can update as needed.No: Comment permission is probably enough.
4

Does this person need to control who else has access?

Yes: Give Edit permission (includes sharing rights).No: View or Comment is appropriate.

​
Permission Level Examples by Role

​
Changing Permissions

You can update someone’s permission level at any time:
1

Open Share Settings

Click the Share button for the process.
2

Find the Person

Locate the team member in the access list.
3

Click Current Permission

Click on their current permission level (View, Comment, or Edit).
4

Select New Permission

Choose the new permission level from the dropdown.
5

Save

Changes take effect immediately. No need to notify the person unless you want to explain the change.
Common reason to change permissions: Promoting someone from View to Comment as they gain experience, or from Comment to Edit when they become a process maintainer.

​
Permission Best Practices

Start Conservative

Give the minimum permission needed. It’s easier to grant more access later than to restrict it.

Limit Editors

Too many people with Edit permission creates chaos. Limit to 2-4 maintainers per process.

Use Comment Freely

Comment permission is great for collaborative culture. People feel heard without risking accidental changes.

Review Regularly

Audit permissions quarterly. Update as people’s roles change or as they gain experience.

​
Common Permission Scenarios

Scenario: Team Member Keeps Asking Questions

Problem: A team member with View permission constantly emails questions about the process.Solution: Upgrade them to Comment permission so they can ask questions directly in the process. This creates a knowledge base for others.
Problem: Multiple people with Edit permission are making conflicting changes.Solution: Reduce Edit permissions to just 1-2 process owners. Downgrade others to Comment so they can still suggest changes.
Problem: A former team member still has Edit permission after changing roles.Solution: Remove their access entirely or downgrade to View if they still need to reference the process occasionally.
Problem: You want team input on a new process before finalizing it.Solution: Share with team members with Comment permission. Gather feedback via comments, then implement suggested changes.

​
Security Considerations

Sensitive ProcessesFor processes containing sensitive information (financials, compensation, legal, personal data):
  • Limit sharing to only necessary people
  • Use View permission by default
  • Only grant Edit to trusted owners
  • Regularly audit who has access
  • Never use public sharing
Compliance ProcessesFor processes subject to audit or regulatory requirements:
  • Track who has Edit permission
  • Consider requiring approval for changes
  • Document why people have access
  • Review access during audits
  • Use version control features

​
Tips for Success

Communicate Changes

When changing someone’s permissions, let them know why. This prevents confusion.

Document Decision Criteria

Create guidelines for your team about who gets which permission level.

Trust Your Team

Don’t withhold Comment permission out of fear. Collaborative input improves processes.

Monitor Activity

If your system shows who’s editing, monitor for issues and adjust permissions as needed.

​
Next Steps

Sharing Processes

Learn how to share processes with your team

Working with Shared Processes

Learn how to use processes shared with you

Collaboration Best Practices

Tips for effective team collaboration