Skip to content

Overview and Concepts

Access in Credence is determined by two separate decisions:

  • Scope - Which records a user can access.
  • Capability - Which actions a user can take on those records.

Keeping these separate helps teams grant access precisely without over-permissioning users.

Key Concepts

  • Portfolio: The main scope boundary used to organize properties and ensuing operational records.
  • Property: The anchor for many operational records (leases, receivables, payables, etc.).
  • Role: The main capability boundary used to define what permissions a user has on in-scope records.
  • Permission Group: A capability bundle that defines what actions are allowed.

How Record Access Works (Scope)

Credence evaluates record visibility from portfolio and property relationships:

  1. A user is assigned access to one or more portfolios.
  2. Properties in those portfolios become in-scope.
  3. Records tied to those properties become visible to that user.

In practice, this means access to a property generally drives access to related operational records for that property.

Common Examples

  • Lease access follows the lease's property.
  • Receivable access follows the related lease/property.
  • Payable access follows the property assigned to payable charge items.

How Action Rights Work (Capability)

After a record is in scope, Credence applies role-based capabilities:

  1. The user has one or more role assignments for the relevant portfolio.
  2. Each role is mapped to one or more Permission Groups.
  3. Permission Groups determine which actions are allowed (view, create, edit, delete, and so on).

Note: Active incoming role delegations may also grant portfolio scope and role capabilities for that portfolio.

This allows a user to have fine-grained and varying authority levels across different portfolios and properties.

To review capabilities, see Permission Groups and the Permission Catalog. The Permission Matrix report (Reports Dashboard → Admin) shows roles versus permissions. The Access Matrix report shows users versus portfolio roles, including delegated access.

Why This Model Matters

  • Separation of duties: You can allow access without granting broad edit or approval rights.
  • Portfolio-specific control: The same user can be an approver in one portfolio and read-only in another.
  • Cleaner governance: Access reviews are easier because scope and capabilities are managed independently.
  • External account access: A property management team can work on different portfolios without logging out and logging back in to different accounts.

Common Scenarios

Scenario 1: Same user, different authority by portfolio

A regional operations user works across two portfolios:

  • Portfolio A: role allows full operational actions.
  • Portfolio B: role allows read-only access.

The user can see both portfolios' records, but actions differ by portfolio context.

Scenario 2: Shared portfolio, different responsibilities

Two users are assigned to the same portfolio:

  • User 1 can prepare and edit records.
  • User 2 can approve workflow steps.

Both can access in-scope records, but only each user's assigned capabilities are available.

Role Delegation

Users with the Delegate role permission can temporarily share their portfolio role capabilities with another user. Delegation is self-service on the delegator's own profile only—administrators cannot create delegations on someone else's behalf.

  • Active delegations add portfolio scope and capabilities for the delegatee without a permanent assignment.
  • Scheduled delegations appear on the profile Delegations tab but do not grant access until they become active.

See Role Delegation for eligibility rules, date limits, and where to manage delegations.

Access Review Best Practices

  • Keep scope and capability assignments simple and consistent. Reviewing access falls to the wayside when complex assignments are used.
  • Keep high-risk actions limited to narrowly defined roles.
  • Avoid creating one broad role for everyone; prefer role design by responsibility.
  • Recheck role mappings when teams, properties, or operating structures change. It is best practice to schedule regular access reviews to ensure roles are still appropriate and up to date.