Project Visibility & Access Governance

Purpose

This document explains how project visibility is controlled within the platform and how different governance layers interact.

The goal is to provide:

• Consistent internal understanding
• Clear troubleshooting guidance
• Predictable client facing explanations

These rules apply globally regardless of how a project is created, including:

• Manual project creation
• Project copy workflows
• API created projects
• Integration created projects (e.g. Certinia)

Governance Model Overview

Project visibility is controlled through two primary governance layers:

1. Account Type Permissions (Primary Governance Layer)

The primary setting controlling project visibility is:
“Access and Edit Projects without an Invitation”

To view a users Account Type :
Employees → Locate Employee > Account Type in Column View

To view Account Type Permissions :
Employees → Account Types

This is the foundational visibility setting within the platform.

Enabled = Open Visibility Model

If enabled:

• Users can access all projects within the workspace by default
• Users do not need to be individually added to projects
• Project visibility is workspace wide unless additional Access Control restrictions apply

Disabled = Explicit Membership Model

If disabled:

• Users cannot access projects unless intentionally added to the Project Directory
• Visibility becomes project specific
• Users must be assigned manually or through integrations/API workflows

2. Access Control Attributes (Secondary Governance Layer)

Access control acts as an overlay restriction layer on top of Account Type permissions.

Access Control does not replace Account Type visibility logic.

It further restricts what a user can access.

Located under:

Workspace Level → Employees → Select Employee → Access Control tab

Client Access Control

Restricts visibility based on assigned client relationships.

Example:

• User may only access projects assigned to:
  • Client A
  • Client B

Even if their Account Type would normally allow broader access.

Project Office Location Access Control

Restricts visibility based on project office location.

Example:

• User may only access projects where:
  • Project Office Location = Singapore

This means:

• If a project does not have a Client assigned:
  • Client Access Control restrictions do not apply
• If a project does not have a Project Office Location assigned:
  • Project Office Location Access Control restrictions do not apply

In these scenarios, visibility falls back to the user’s Account Type permissions.

Example:

A user may be restricted to:

• Client = Zebra only

However:

• if a newly created project does not yet have a Client assigned
• and the user’s Account Type allows:
  • “Access and Edit Projects without an Invitation” = Enabled

Then:

• the user may still temporarily see/access the project until the relevant access controlled fields are populated.

This is expected behaviour.

Effective Visibility Logic

Final visibility is determined by:

Account Type Permissions

PLUS

Access Control Restrictions

Examples:

Troubleshooting Checklist

When a user cannot see a project:

Step 1

Check:

“Access and Edit Projects without an Invitation”

If disabled:

• Confirm the user has been added to the Project Directory

Step 2

Check:

Access Control Attributes

Validate:

• Client access restrictions
• Project office location restrictions

Step 3 (If Step 2 has access control applied)

Validate the project itself has the relevant access controlled fields populated.

Check:

• Is a Client assigned?
• Is a Project Office Location assigned?

Important:

• If these fields are blank/unassigned, the related Access Control restrictions will not apply
• Visibility will instead fall back to the user’s Account Type permissions

---

Key Principle

Account Type Permissions determine the baseline visibility model.

Access Control then acts as an overlay restriction layer on top of that visibility model.