A Portal member who belongs to an organization can see the organization’s people, add or edit them, update the organization profile, and manage child organizations when you allow those actions. Their access depends on two settings working together: the feature switch for your Rhythm account and the permission grid you set by contact role. Use this article to configure both settings and check why a Portal member cannot see or manage their organization’s contacts when the feature looks enabled.
Prerequisites
- You need access to your account’s Contacts setup, including Contact Role Permissions, and to Settings for the child-organization switches.
- Contact roles must already exist because the permission grid shows one row for each active contact role. Review your contact role setup before you configure these permissions.
Where to Find It
Go to Rolodex (CRM) › Setup › Contacts › Contact Role Permissions. The page explains: "Permissions dictate what actions contacts are allowed to take on behalf of their organizations in the portal."
The Permissions Grid
The grid shows one row for each active contact role. It also includes an All Contacts row, which applies to every Portal member who belongs to an organization, regardless of their roles. Each row has a checkbox under nine permission columns:
| Permission | What it grants on the Portal |
|---|---|
| View Contacts | See the organization’s people |
| Edit Contacts | Edit a person’s details |
| Remove Contacts | Detach a person from the organization |
| Create Contacts | Add a new person to the organization |
| Update Organization Info | Edit the organization’s own profile |
| Manage Child Organizations | See and open the organization’s child organizations |
| Create Child Organizations | Create a new child organization |
| Edit Child Organizations | Edit an existing child organization |
| Delete Child Organizations | Remove a child organization; the Portal calls this "Remove" |
When a role is marked as an administrative contact role in that role’s settings, its row shows this sentence instead of checkboxes: "This is an administrative role, and is automatically granted all permissions for their organization." Anyone with that role automatically receives every permission, and you cannot turn those permissions off on this page.
A member receives a permission when any role they hold grants it, or when the All Contacts row grants it. One permissive role is enough, even if the member also has a more restrictive role. If your account has never saved any permissions, every action is denied except for members with an administrative role.
A member without Update Organization Info, such as someone with an ordinary employee role instead of an administrative role, cannot rename the organization or edit its details. These permissions do not let a member delete their own organization record.
A contact can be associated with, and act on behalf of, only one organization at a time. Rhythm does not support attaching one contact to more than one organization at once, so these permissions always apply to a single organization for each member.
Warning
Saving this page replaces the full saved permission list with the boxes currently shown in the grid. Because the grid shows only your account’s active contact roles, a role that is inactive when you save is removed from the saved list. If you reactivate that role later, its permissions start over with every box unticked. Avoid saving this page while a role you care about is temporarily deactivated.
Child Organization Settings
Child-organization actions also need a matching switch on the CRM settings page, in addition to the permission grid.
Go to Rolodex (CRM) › Setup › Settings. Tick Allow contacts to manage child/descendant organizations in the portal to show the Child/Descendant Organization Settings card:
| Setting | Effect |
|---|---|
| Name in Portal (singular), Name in Portal (plural) | Sets the words the Portal uses for one and several child organizations, such as "division" and "divisions". Both fields are required once the card appears, and they default to "division" and "divisions" |
| Allow for creating new child organizations in the portal, with a form picker | Turns on child-organization creation for your account and selects the organization web form the Portal uses |
| Allow for editing new child organizations in the portal, with a form picker | Turns on child-organization editing for your account and selects the organization web form the Portal uses. If you leave this blank, the Portal uses the create form |
| Allow for deleting new child organizations in the portal | Turns on child-organization deletion for your account |
A member can create, edit, or delete a child organization only when both the matching switch here is on and their contact role grants the matching permission in the grid above: Create Child Organizations, Edit Child Organizations, or Delete Child Organizations. If you turn off a switch here, the Portal hides that action even for a member whose role otherwise allows it.
These settings work in one direction only. They let a parent organization’s contacts manage its child organizations and their contacts. A contact associated with a child organization cannot use these settings to view or manage the parent organization’s contacts from the Portal.
Tip
An organization’s type is normally chosen and changed in the Console, not by the Portal member creating or managing the organization. Do not expect a portal user to see a type picker when they create an organization.
A member can edit another contact’s roles on the Portal only when their permissions allow editing contacts and the selected edit contact form includes the built-in Contact Roles field on its field group. If permissions look correct but role editing is still unavailable, check that field on the form before you assume it is a permissions issue.
Tip
The Manage Your Account contact role picker in the Portal has been reported to show every contact role, even when the organization’s type is configured to limit contacts to only a specific subset of applicable roles.
The Portal forms that organization administrators use to add and edit an organization’s people are set separately. Go to the Configure Default Contact Forms dialog under Rolodex (CRM) › Setup › Contacts › Forms and use these pickers: When an organization administrator is creating a new organization contact: and When an organization administrator is editing an existing organization contact:. See Configure Contact Forms, Data Rules, and Communication Types for the Console side of that same dialog.
Why a Member Cannot Do Something
If a Portal member cannot view, add, edit, or remove their organization’s contacts, or cannot manage a child organization, check these settings in order:
- Does any role the member holds grant the permission, either directly or through the All Contacts row? Remember that an inactive role’s saved permissions are dropped the next time you save this page.
- For a child-organization action, is the matching account-wide switch on in Settings? The switch and the role permission must both be on.
When you change permissions while a member is signed in, their open Portal page does not update until they reload it. The change takes effect on their next page load.
Contact-role permissions do not, by themselves, control whether a portal user can set or change their own organization on a profile or new-join form. Setting up an organization association from those forms also depends on the form’s own configuration and on backend authorization behavior beyond the contact-role permissions described here, so a member can still be refused even when their role permissions look correct.
An organization administrator with an administrative contact role should have full access to their organization automatically. That role has also been reported to return Access Denied when creating or editing contacts from the Portal, though the issue has not been consistently reproducible. If an administrator sees this even though their role and permissions look correct, contact Support.
Warning
Whether the organization on a new-join or add-contact form was auto-resolved, for example matched by email domain or already pre-filled, rather than chosen or typed manually, has been reported to sometimes affect whether the save succeeds. If a member cannot save a new contact and the organization was auto-filled, have them select or confirm the organization manually before saving.
Parent-child organization relationships also affect invoicing, separately from the contact and organization management permissions above. A parent organization, or a user with payment permission, can view and pay a child organization’s invoices and manage its contacts. A child organization cannot see or manage the parent’s invoices or contacts. For a group registration under a parent organization, a participant who does not have an administrative role or payment permission cannot view the invoice or pay only their own portion. Only someone with an administrative role or payment permission can make the payment.
Permissions
To set the permission grid, you need access to your account’s Contact Role Permissions setup page. To set the child-organization switches and forms, you need access to Settings.
Validation and Errors
The permissions grid has no field-level validation, so you can tick or untick any checkbox and save. If the save fails, you see Unable to save settings with the underlying reason, and your grid changes stay on the page so you can try again. Once the child-organization card is shown, both name fields are required. Once creation is allowed, you must choose a create form. Once deletion is allowed, you must choose an edit form, not only when editing is allowed; this rule is easy to miss if you turn on deleting before choosing an edit form.