WoodsPortal separates object permissions from resource permissions so administrators can control record access and actions such as file, folder, note, email, and profile operations.

Configure object permissions

1. Open the relevant portal role.
2. Locate the object-specific permissions.
3. Enable read access only for object families the role must view.
4. Enable write access only where the role must create or modify records.
5. Treat delete access as separate. Do not promise a customer-facing delete interface while that behavior remains unverified.
6. Save and test the role against representative records.

Configure resource permissions

• File and folder permissions control file browsing and create actions.
• Note permissions control note visibility and note changes.
• Email permissions control available email interactions.
• Profile and other resource permissions control their corresponding actions.

Effective access

• The user needs access to the active portal.
• The role must allow the object and the requested action.
• Record scope, contact linkage, association access, property visibility, and portal configuration can narrow the result.
• A coarse content permission alone does not satisfy object-data access.

Test the role

1. Sign in as a safe test user.
2. Confirm that permitted objects and resources are visible.
3. Attempt one permitted write action.
4. Attempt one intentionally denied action.
5. Adjust only the permission responsible for the unexpected result.

Figure: Object-level display, create, update, public-access, file, note, and email controls.