Special permissions and interface visibility
How entity-specific actions affect routes, modules, tabs, buttons, and sensitive data.
Some remoteEaze operations need a permission more precise than Create, Read, Update, Delete, or Export.
Important special permissions
| Entity | Special permission | What it controls |
|---|---|---|
| Activity Log | Decrypt | Reveals encrypted sensitive values in an activity-log detail diff. Read alone returns encrypted values. Using decryption is itself audited. |
| Delivery Log | Decrypt | Reveals encrypted third-party response headers and bodies. Read alone returns a protected representation. Using decryption is itself audited. |
| Transaction | Reverse | Initiates the controlled reversal path; it is not a Delete action. |
| Transaction | Override FX Rate | Allows a non-system exchange rate to be entered with the required supporting evidence. |
| Notification Configuration | Publish | Sends an announcement to the selected audience; configuration access alone does not grant publication. |
| Customer Application, Loan Application, Loan Variation, Fixed Deposit Application | Assign | Routes, claims, or accepts the current workflow stage. |
| Customer Application, Loan Application, Loan Variation, Fixed Deposit Application | Process Workflow | Allows ordinary workflow decisions and valid transitions. The underlying action is verify; workflow state, assignment, scope, and configured actions still decide what the user can do on a particular record. |
| Customer Application, Loan Application, Loan Variation, Fixed Deposit Application | Waive | Allows a configured waivable exception to be recorded with a reason. It does not grant ordinary workflow decisions. |
| License | Update Config, Update Contract | Separates organization-facing configuration from platform contract, limit, and module changes. |
For customer onboarding, creating the live customer or retrying its configured
post-action is part of normal workflow processing; it does not use a separate
Create Customer role permission. CREATE_CUSTOMER can still appear in workflow
configuration as an action type that describes what the product should do. It
is not a role permission.
Why something may not appear
remoteEaze uses several visibility checks, each for a different part of the interface:
- Application shell: Dashboard Access and Field Agent Role decide whether the Dashboard or Workbench can be opened.
- Sidebar module: most modules appear when the user has Read on at least one entity represented by that module. Licenses are system-scope only. Unlisted modules fail closed.
- Route: opening a protected URL requires its entity/action permission even if the URL is known.
- Tab: permission-bound tabs require Read on their entity. An index route sends the user to the first visible tab.
- Button or form action: Create, Update, Export, approval, and special-action controls are shown or enabled from the resolved permission.
- Workflow action: current stage, configured action or transition, assignment, record status, data scope, waiver configuration, and separation of duties can hide or disable an otherwise permitted action.
The interface is a guide to available actions, but the server repeats the authorization check. Hiding a button is not the security boundary.
Read does not mean every field is readable
Activity logs are the clearest example. A user with Read Activity Log can open a permitted log. If the log contains sensitive encrypted values, the Decrypt PII control appears only for a user with Decrypt Activity Log.
This pattern should be considered whenever a task uses sensitive, exceptional, or financially consequential actions: check the specific permission named in that task's Access note rather than assuming Read or Update is sufficient.
If a user expects an action but cannot see it, check in this order: application access, entity/action permission, data scope, record status, maker-checker separation, current approval level, and matching access policies.