SCHOOL ERP ROLES & PERMISSIONS

Give every school role a clear relationship to the work it handles.

A school’s administrative work is shared across people with different responsibilities. The person reviewing a student record may not be the person recording a fee collection; someone preparing a report may need a different level of access from the colleague responsible for maintaining source information. A permission model helps the institution express those distinctions inside its product account.

Explore published capabilities

Assigned user rolesRoles

Module permissionsAccess

Permission changesHistory

Role permissions

Assigned user rolesInstitution-definedRoles

Module permissionsView, create, update, deleteAccess

Permission changesTracked changesHistory

Conceptual product view · no customer records or performance figures

Access as institutional design

Start from responsibility, then shape access.

Roles and permissions work best when they reflect the way the institution assigns responsibility. Before configuration, school teams can map the work they expect each role to perform and the boundaries that should apply to that work.

That simple discipline changes the way a product conversation unfolds. Teams can connect the feature under review to the people who use it, the records it touches and the next decision someone needs to make. It also gives the institution a practical way to distinguish what the product supports from what belongs to its own process and policy.

01 / ROLE

Describe the work before naming the role.

A role is a way to group responsibilities; it should not be treated as a title alone. School ERP supports multiple staff/user roles, custom roles and assigning roles to users. That gives the institution a basis for aligning access with its internal operating structure.

During setup, schools should identify which teams work with admissions, student records, fees, attendance, academic administration or reports. The exact role names and membership remain institution decisions rather than a universal template imposed by the public website.

02 / MODULE

Apply permission decisions where the work happens.

The declared permission model includes module-level permissions and view/read, create, update/edit and delete actions. Print and export permissions are also included. This lets a school discuss access in relation to modules and the specific actions staff are expected to perform.

The important evaluation question is how those controls are represented and maintained in the product account. A demonstration can walk through a representative school workflow and help the team verify which permission options apply to that module.

03 / NAVIGATION

Make available work easier to distinguish.

Permission-based navigation visibility is part of the declared capability. It connects access decisions with the parts of the product staff see as they move through their work.

This can make role conversations more concrete: which modules should be visible to a given user, what actions should be available there and how should the institution review a change when someone’s responsibilities shift?

04 / REVIEW

Keep role changes within a reviewable process.

Role and permission changes are tracked in the declared School ERP scope. That gives administrators a basis for reviewing changes to access configuration as part of their institutional oversight.

Schools should still define their own internal approval practice, account ownership and periodic access review. The product supplies declared controls; the institution determines the governance process around them.

Permission model

Think in modules and actions.

School ERP declares module-level controls across view/read, create, update/edit, delete, print and export. The table describes the types of controls; it does not imply every action is available in every module.

ControlHow to evaluate it

View / readReview information within the access assigned to a role.

CreateAdd a record where the relevant module supports the action.

Update / editMaintain existing information where the module permits changes.

DeleteControl deletion actions according to the school’s assigned access policy.

PrintAllow printed output where available and authorised.

ExportControl export actions where the module and role support them.

Available actions depend on module and configuration. The institution determines user assignments and internal approval policy.

A USEFUL PRODUCT REVIEW

Bring a real role map to the product review.

List the teams who use the system, the records they handle and the actions they need to perform. Include less frequent actions such as printing, exporting or correcting a record; these are often where role assumptions become unclear.

Then review role creation, assignment, module-level controls, navigation visibility and the recorded history of permission changes. This makes the discussion concrete while leaving the institution in control of its own access policy.

Bring your team’s real process into the discussion and ask the CodePex representative to demonstrate the declared workflow in context. Where a detail depends on configuration or institution policy, establish that requirement before deciding how it should work in your environment.

CONTINUE WITH SCHOOL ERP