Appmint Roles, Permissions and Password Policy: Record, Page, Menu and Sign-in Rules

Roles, records, pages and menus

Cedar & Form needs Maya Chen to handle incoming enquiries. She should read, create and update lead records, without deleting them, approving decisions or editing page components. Her navigation should lead to the enquiries work, while the administrator retains a separate account for configuration. This is the starting permission profile; you will also build a page-editor alternative and practise removing access.

A role supplies permissions. A group supplies membership and can grant roles to its members. A person's effective access can therefore come from direct role assignments and several groups. Looking only at the role you are editing misses those other sources. Before changing Maya's account, open her profile in User Management and note her direct roles, group memberships and inherited roles. Use a training account without Owner, RootAdmin or RootUser privileges for the colleague side of this exercise.

Record permissions describe actions on records. Page permissions describe actions on components. Menu access describes which screens are available. These controls answer different questions: a visible Leads link does not by itself authorize changing a lead; permission to update records does not by itself add that link to navigation. A role name such as cedar-enquiry-editor is an identifier, not a rule restricting records to Cedar enquiries. Collection access, ownership, workflow state and server authorization can impose additional conditions.

Use a training organisation containing disposable lead records and a draft page. Create the records through the CRM course or your normal Leads form and give the lead a recognisable training name such as Cedar permission practice. Avoid deleting a real lead merely to demonstrate a denied action. Keep an administrator session available in one browser profile and Maya's session in another so that each result belongs to the correct identity. Record the organisation shown in each session before starting.

The finished example will contain a saved custom role, a group granting that role, Maya's membership, and observed allowed and denied actions in Maya's fresh session. A list of selected checkboxes is an intermediate result. The colleague's actual experience is the final result of the exercise.

System roles and custom role creation

Open Configuration → Role & Permission. The Role Manager sidebar lists available roles; New Role opens a blank custom role in the main editor. On a narrow screen, use Roles to reach the sidebar. Always read the selected role name before changing permissions. The separate Menu Access entry opens the same manager in its menu view and can initially select the built-in User role; it does not mean your custom role is selected.

First select a system role and inspect its badge. Its name, description, record permissions and page permissions are read-only in this editor. Menu access remains editable. The read-only banner therefore has a specific scope: it does not disable the menu panel. Do not change a shared system role for this first exercise, because its menu changes may affect many existing colleagues.

Now create the Cedar role:

1. Click New Role. Enter cedar-enquiry-editor in Name.
2. Enter Cedar & Form enquiry staff: read, create and update leads; no deletion or page editing in Description.
3. In What this role can do with records, select Read, Create and Update. Leave Delete, Review and Approve clear.
4. Expand What this role can do on pages and leave its four permissions clear.
5. Click Create role at the bottom of the form. Wait for the save to finish. If an error appears, keep the form open and correct it before continuing.
6. Select another role and return to cedar-enquiry-editor, or reload the manager and select it again. Read back its description and the three selected record permissions.

Names accept letters, numbers, hyphens and underscores. Spaces and punctuation such as & are not accepted in the identifier; use the description for readable wording. The saved name is immutable in this editor, while a custom role's description remains editable. Choose the identifier before assigning it to groups. If you need a different identifier later, create a replacement role, transfer intended assignments and test the replacement before retiring the old assignment.

A successful first save changes the primary action from Create role to Save role and makes Name read-only. The sidebar also has Save for custom roles. Prefer the form's primary action for creation because it presents name validation with the form. Do not treat switching roles or closing the screen as a save.

System roles have predefined capabilities. Editing their menus creates or updates the organisation's saved representation of that role; it does not rewrite the platform's global built-in definition. For a job with different record or component capabilities, make a custom role instead of trying to unlock disabled system-role checkboxes.

Record permissions and job responsibilities

The six record permissions let you describe different responsibilities without assuming that everyone who can read information should also change it. Read opens and views records. Create adds records. Update changes existing records. Delete removes records. Review concerns items waiting for a decision, and Approve concerns signing those items off. The editor exposes separate checkboxes; selecting Review does not automatically select Approve.

Return to the saved cedar-enquiry-editor role. Read, Create and Update should be selected, and the section should report three grants. That combination describes Maya's intended work. It does not identify a particular collection and does not select the CRM screen. Leave the role at these three permissions while you configure navigation in the following section.

For a read-only variation, create cedar-enquiry-reader with only Read selected. Use the description Cedar & Form enquiry observation; no record changes. Save it, then give it only the menus needed for the intended reading task. Test with a second training account or replace the editor role temporarily; adding reader to an account that already has editor will not remove the editor's update grant.

For a review workflow, create cedar-enquiry-reviewer and choose Read and Review initially. Open a training item already waiting for review in a module that implements that workflow. Review and approval are meaningful only where the module has corresponding states and actions. If the colleague must also sign off, add Approve, save and repeat the same item-stage exercise with a fresh session. Do not assume an approval queue appears simply because the checkbox is selected. Nor should you grant Create, Update or Delete by habit when the task is only reviewing.

A practical decision table for the main Cedar role is:

A hidden action establishes a UI outcome; it does not alone establish that the server rejects a direct request. In an authorised test environment, use the same module's documented API with the colleague's own credentials to check the denied operation as well. Do not copy an administrator request with administrator credentials and call it a colleague test.

If Update still works after removing it from this role, inspect every role and group applied to the account, refresh the account's session, and examine collection or module rules. If a permitted save fails, read the error before changing permissions: a required field, invalid record state or missing collection-level rule can fail independently of the role.

Page-component permissions and the editor role

Expand What this role can do on pages. The four permissions are View, Add, Remove and Configure. They refer to seeing components, placing new components, taking components off a page and changing component behaviour. They are separate from record Create, Update and Delete. A person who maintains lead data does not need component editing capabilities merely because the data appears on a page.

Keep all four clear on cedar-enquiry-editor. For the alternative Cedar page-maintenance job, create a separate custom role named cedar-page-editor, with description Cedar & Form draft page maintenance. Give it View, Add and Configure, leaving Remove clear for the first test. Choose any record permissions only after considering the draft-page workflow you are authorising; page components are stored and loaded through application services, so the component controls alone are not a promise that every editor action will succeed.

Save the role and give it the Build Studio menu entries needed for the exercise. Assign it to a separate training colleague or replace Maya's earlier assignment temporarily so that the test does not combine unrelated grants. Use an unpublished practice page with a heading Cedar component practice and an expendable text component. Record the page's initial saved state in the administrator session.

Sign in as the page editor. Open the draft page and try viewing its components. Add a text component containing Training hours: Monday to Friday, then change its configuration through the actual component controls. Save the page using the editor's own save action, reopen it and read back the value. Role saving and page saving are separate operations: saving permissions does not save a page draft, and saving a page does not change a role.

Next attempt to remove the expendable component. The intended role profile lacks Remove. Observe the actual control and outcome. If removal succeeds, stop and inspect the account's other grants and the editor's enforcement rather than claiming that the role worked. If an action is simply unavailable, record that UI result and keep server enforcement as a separate test.

To demonstrate a complete page-maintainer role, the administrator can add Remove, click Save role, refresh the colleague's session, and repeat removal on the expendable component. Reopen the page to confirm the persisted result. Use a new expendable component if the first attempt unexpectedly succeeded.

None of these four labels says Publish. Publishing can involve other menus, organisation configuration and deployment-specific authorization. Teach publication through the Build Studio course's explicit save, preview and publication steps, then check that action independently for the colleague. A visible editor or a Configure grant is insufficient evidence of publishing permission.

Appmint, Business Made and Mobile app menus

Select cedar-enquiry-editor and scroll to Menu access. The tabs are Appmint, Business Made and Mobile app. The application you opened the editor from places its web tab first; Mobile app remains last. Each tab shows a catalogue of screens grouped into sections, with a selected count. The item also displays its route path. Read both the label and path when similar labels appear in different areas.

For the enquiry example, open the Appmint tab, find Leads in the CRM section, and select that item. There are other Leads entries for other modules, so use the CRM grouping and displayed path to choose the intended one. Expand only the work menu required by your exercise. Selecting a section heading toggles its items together; selecting a single row changes that route. When two labels point to the same route, their selection can move together because the stored grant is the route, not the display label.

Historical LeadEditor draft with CRM Leads selected. This is a different role name from the Cedar exercise; Create role is still visible, so the image does not establish a saved grant. It shows how the CRM grouping and route distinguish the intended Leads screen. The older capture shows the two web-app tabs; use the current Mobile app controls described below rather than assuming that older catalogue is complete.

Open Business Made and examine its catalogue separately. Select the actual Business Made destination only if this colleague performs a corresponding job there. Return to Appmint and confirm the Leads selection remains. A tab change does not discard the other tabs' route selections: all three contribute to one role menu profile. Save only after reviewing the combined selection.

Mobile has a particularly important starting condition. Until the role names a mobile path, the mobile panel describes No mobile restriction. Selecting web routes alone therefore does not mean the phone app is denied. On Mobile app, select the specific available mobile work item required for the training account, using the actual displayed catalogue. The first mobile selection changes that app to a selected-items profile. Keep the item name and route in your exercise notes because the catalogue comes from the installed SDK and may differ by release.

If the job has no mobile requirement, do not invent an empty-tab deny rule: a cleared mobile selection returns the no-restriction condition for that role. Use the organisation's appropriate account/device policy and test the actual phone app. The global No access control discussed next applies across the role and is not a way to deny only one app while retaining selected web access.

Click Save menu access, wait for the response, and reopen this same role. Read the three tabs again. Finally sign in as Maya and inspect the relevant application. The editor's selected count describes configured routes; the application may also apply account type, organisation features, other roles and route guards. A mobile device may hide more than the allowed mobile selection, so use an actual authorised mobile session for the phone outcome.

If a newly granted screen does not appear, first confirm the correct role and organisation, then the exact route and app tab, then the person's current roles. A feature unavailable to the organisation will not become available merely because its menu item is selected. Avoid broadening every menu just to solve a single missing entry.

Menu presets, broad access and save controls

The controls above the menu tabs have different meanings. Use a disposable custom role named cedar-menu-practice to compare them, so the comparison does not disturb Maya's working role. Save that new role before experimenting and keep it unassigned until a particular profile is ready for testing.

Preset… replaces the current route selection with the chosen preset's menu paths. It is a starting menu layout, not a command that changes the role's name, record permissions or component permissions. Choose a preset, inspect all three tabs, then add or remove individual routes as necessary. Reapplying a preset after customising the list can replace those custom selections. A preset whose resolved path list is empty becomes explicit No access in this editor.

Select all selects the currently available catalogue paths across all three tabs, not only the tab on screen. It stores an explicit list. This distinction matters when the product later adds a new screen: a list assembled from today's catalogue is different from an unrestricted policy. After clicking it, inspect the counts on Appmint, Business Made and Mobile app before saving.

Allow everything clears the explicit include and exclude lists. For a custom role, this is the editor's no-restriction menu setting. It is not a grant of every record action or component action. Built-in roles can also carry default menu tiers in the signed-in profile; runtime handling may resolve a built-in default when its explicit web list is empty. Check the actual built-in role with a nonprivileged account instead of assuming this button overrides every built-in default.

No access clears the include list and records an explicit deny-all marker. It is different from clearing the last individual checkbox. For an ordinary staff profile, the current web menu logic gives this explicit deny priority over other ordinary menu grants. Platform operators and roles defined as all-access are handled earlier, so Owner or root accounts are unsuitable for proving ordinary restrictions. Customer and workspace guest identities have their own navigation rules as well.

To compare these settings, select an explicit menu item on the practice role, save and reopen it. Then choose No access, save and reopen. Note that the panel now says No access. Next choose Allow everything, save and reopen; note the changed summary. Restore the intended explicit list before assigning the role to a colleague. If you test No access with a dedicated account, an application landing or welcome screen may still be reachable. No access is a menu policy, not an account lock or token revocation action.

The menu panel has Save menu access; the custom-role form has Save role, and its sidebar has Save. These are separate visible save actions, but they currently serialize the same role object. If you change record permissions and menus before pressing Save menu access, that save can persist both changes. Do not treat either button as an isolated transaction over only its nearby controls.

Use a clear working sequence: finish record/page permissions, Save role, reopen; then finish the menu profile, Save menu access, reopen. For a system role the menu button is the available save route because the general role controls are read-only. On failure the panel keeps an inline error; the selected ticks alone are not evidence of persistence. Read the failure, correct it, retry once appropriate, and reopen the role before moving to colleague testing.

Group grants and direct role assignment

Once the editor role has a saved menu profile, assign it through a group. Open User Management → User Groups and create or edit cedar-enquiries. Use Description Cedar & Form enquiry handling team. In Roles this group grants, add cedar-enquiry-editor. Select Maya's training account by its controlled email address in the membership controls. Click Add 1 to stage Maya as the selected member, then click Create group or Save group to persist the change.

Historical unsaved group form: LeadEditor is available but unchecked, and the selected-role count is zero. The front-desk text is the name-field example, not proof of an existing Cedar group. Select your actual saved role and intended member, save, and reopen both the group and the person to prove the relationship.

The group operation saves the group and then applies added or removed explicit memberships to the affected users. Reopen both the group and Maya's profile afterwards. A group-save message should not be the only evidence for a membership change; a later membership request can fail separately. The saved result should show the named role on the group and Maya as an explicit member, with the corresponding inherited role in her profile.

Groups can also show members present through a role relationship. The group editor distinguishes these from explicitly added members, and they cannot be removed by the explicit-member control. If Maya appears through such a relationship, trace that underlying assignment rather than repeatedly trying to remove her from the visible list. Built-in group roles can be fixed rather than freely removable. Work in the custom Cedar group for this lesson.

A direct role assignment is useful for a deliberate individual exception. The current modern profile supports removing certain direct roles for an eligible administrator, but it does not expose a corresponding general Add role control. Do not search indefinitely for one based on an older screenshot. Use the group workflow for the ordinary visual lesson. For administrators with an authorised API workflow, the application service exposes this advanced alternative:

{
  "email": "<Maya's controlled training-account email>",
  "roles": ["cedar-enquiry-editor"]
}

Use the organisation and authentication mechanism already configured for your approved API client. The base URL placeholder is not a hostname to paste literally. The email placeholder must be replaced with the actual training account, and the role must already exist under the exact saved name. Keep tokens and session headers out of screenshots and course notes. This request changes access when sent; submit it only for the training assignment you intend.

Read the API response, reopen Maya's profile, and distinguish the new direct assignment from group inheritance. To remove that direct grant through the same API workflow, use POST <configured API base>/profile/user/role/remove with the same email/roles payload. An HTTP success alone is insufficient for the lesson: follow it with the refreshed profile and the colleague's fresh sign-in.

Avoid leaving both a direct assignment and a group grant accidentally. They can be intentional, but removing one will not demonstrate full revocation while the other remains. Record why each source exists, then choose one source for the basic Cedar exercise.

Allowed screens, denied actions and fresh sessions

Now use Maya's separate browser profile. Sign out and sign back in after the administrator's role and membership saves, or use the product's supported session refresh and inspect the returned identity. The current profile carries resolved roles and permissions, so an older open tab may not reflect a recent change.

Start with the allowed workflow. Open the Appmint CRM Leads screen through the visible menu. Open Cedar permission practice, read its details and make a harmless change to its training note. Save the lead with the module's own save action. Reload or reopen it and read the changed value. Create a second disposable lead through the normal form, supplying the required values shown by that form, and reopen it after saving. These outcomes demonstrate the intended Read/Create/Update path under the actual account.

Next test the intended boundaries. Inspect Delete on a disposable lead. If it is absent or disabled, record that exact UI result. If it is available, attempt deletion only on the disposable record and observe whether the server accepts or rejects it. Check the record afterwards from the administrator session. An unexpectedly successful delete is a failed restriction test, even if the role editor still displays an unchecked Delete box.

Test a restricted screen both through navigation and through its actual URL. Copy the administrator's URL for a training-only configuration destination, then open it in Maya's browser profile. Observe the route guard, displayed screen and any loaded data. Do not invent a URL from its sidebar label or assume hiding a menu prevents a direct URL. Record both the menu result and the direct-navigation result. If the screen opens, inspect other assigned roles and report the remaining authorization issue before calling the role ready.

Repeat the relevant component tests only with the cedar-page-editor alternative. Keeping those tests separate makes it clear which role grants which operation. Where an approval workflow exists, attempt the real review and approval actions at the correct workflow state. A missing workflow or an invalid test item cannot establish that Approve is denied.

Use a simple observation sheet with columns for account, organisation, role sources, application, action, intended result, actual result and saved-state check. Enter what happened: for example, Update allowed; training note remains after reload, or Delete visible; server refused; record remains. Avoid substituting checkbox unchecked for an action result.

If the UI fails before it reaches the permission check, resolve the actual issue first. A network failure, missing record, invalid required field, feature entitlement or expired session is not evidence of a denied permission. Re-run only the affected case after correction. A completed permission profile has both successful intended work and observed boundaries; neither side alone is enough.

Access removal and role maintenance

For the final exercise, remove the source of Maya's editor access. In the administrator session open cedar-enquiries, remove Maya's explicit membership, and Save group. Reopen the group and her profile. If she has a direct cedar-enquiry-editor assignment, remove that separately through the available direct-role removal action or the authorised API method from the previous section. The profile's removal controls are restricted and protect roles such as Owner and system roles; do not use a privileged account as the disposable subject.

Refresh Maya's session and repeat the same Leads screen, direct URL and training-record action cases. Use the same observation sheet so the before and after results are comparable. Confirm the remaining role sources rather than expecting an account with baseline User permissions to become completely unable to sign in. Removing one business role is not equivalent to locking the account or revoking every device.

If access remains, work through its sources in order. Reopen the account after the save, check direct roles, check every group, identify any all-access role, then sign in afresh. Check whether the intended restriction was a menu selection, a record action or a collection/module rule. An inherited grant cannot be removed by deleting an unrelated direct grant. A No access menu test also has different semantics from removing an update permission.

After the revocation exercise, restore only the assignment that Cedar intends to retain. Reopen the group, refresh Maya's session and repeat one allowed and one denied case. Keep the administrator recovery session separate throughout; there is no need to grant Maya Owner to make the workflow pass.

For ongoing changes, edit a role according to a named job responsibility. Before changing a shared role, identify its directly assigned users and granting groups through the available directories. Test the proposed profile with a training account first. Save one coherent change, read it back and re-run the affected operations in each application the role serves. A mobile-only adjustment still deserves a mobile test, and a web-menu change does not establish record enforcement.

If a new responsibility should apply to only some members, create a separate custom role or group assignment instead of broadening the shared role silently. For an identifier change, create the replacement role and migrate assignments deliberately; the Name field on the existing saved role is not editable. Keep the old assignment until the replacement's intended operations work, then remove the old grant and repeat the denied cases to catch permissions it had contributed.

The Cedar exercise is complete when the saved role and group explain Maya's effective access, the intended actions persist their results, denied actions actually fail in the tested paths, and removing the grant changes her refreshed access as expected. Keep any untested application, physical device, workflow or API case as an open item in the observation sheet rather than assuming that one web screenshot covers it.