PASIprep Button/Function Link Guidelines

This is a Navigation Pattern for PASIprep UI Guidelines to outline the use of Buttons and Functional Links (as opposed to navigational links) within PASIprep.

Hiding Functionality

A Button/Function Link/Subsection Tab/Content Section/Page/Action Column should not be visible to a user when:

Generally, the logic to hide a function link/button's should mirror the security rules of the screen where the function would be performed in (if one exists) User must have Level 11 Permission to access the “Edit Disclosure Restriction” screen to edit the record. Users without L11 will get an error if they attempt to access the screen. Thus, any [Edit] links that goes to the “Edit Disclosure Restriction” screen should be hidden to users without L11 (e.g. on the Action Toolbox of a View screen or the Grid Action Menu Bar of a Business Object Grid for Disclosure Restriction)
The user does not have the right PASIprep Permission Level to access the data/function The user does not have PASIprep Level 02 Permission - Modify Student and therefore cannot add/update a Mailing Address.
If it's a record related to a student, the user does not have the right Association level to the Student to view the data and/or perform the function. A user's school is not associated to a student and therefore the Mark Information content section of the record is hidden on the View Diploma Exam Mark screen.
It does not make sense for a user to perform it when the action is in a delete/undelete state. The Delete or Edit functions should not be visible on a Deleted record. Undelete should not be visible on a record that's not deleted.
Data is not in the right status (note: this only applies to the record's main 'status' field, e.g. the Document Order Status for Document Orders) for the action to be performedA school user cannot edit a Diploma Exam Mark when its status is not “Registered”, thus [Edit] should be hidden when the Exam Mark Status is not Registered.

Disabling Actions versus Letting Actions Fail

Actions (buttons/links) should not be disabled. If the action was not hidden (based on the guidelines for hiding buttons mentioned above) but there exist a business rule for preventing an action from occurring by design, then the user should still be able to attempt to perform the action, but the action would fail and user would be presented with an error.


  • Some dialogs may require button to be disabled (instead of leaving actions enabled and showing an error dialog if it's an invalid operation) because of technical limitations where a dialog cannot trigger another dialog to be shown.
  • During long running requests, functions/buttons are disabled to prevent user from firing too many operations when not all server operations are completed.