Applications / App Library
A governed catalog for official ERPat applications, installers, versions, release notes, media, reviews, visibility rules, and download history.
Purpose and What Problem This Solves
The Applications module solves the common problem of scattered installers, unclear versions, and unsafe download links. It gives the organization one official catalog where users can find the correct app, understand what changed, download only what they are allowed to access, and leave feedback after use.
Who normally uses this module
What You Can Do Here
- Publish an official app listing with screenshots, descriptions, tags, and support notes.
- Add versioned installers with changelogs so users know what is new before upgrading.
- Control visibility by role, tenant, or audience instead of sharing files manually.
- Track downloads and reviews to see adoption, quality issues, and support demand.
- Offer public or tenant-less catalog access for approved guest-facing applications.
Core Concepts and Terms
Learn these words first. Most user mistakes happen when a beginner opens a form without knowing what the record represents.
Application record
The main catalog entry. It explains what the app does, who should use it, and where users can get it.
Version
A release of the app with its own changelog, package link, and status. Treat every upload as a controlled release.
Visibility rule
A rule that decides who can see or download a listing. Use this for private apps, tenant-specific apps, and staged releases.
Media
Screenshots, icons, and supporting visuals that help beginners recognize the app and confirm they are installing the right tool.
Download log
The audit trail showing who downloaded what, when, and from which tenant or account context.
Review
User feedback and ratings that help maintainers prioritize fixes, documentation, and training.
Beginner Quick Start
Use this first-run path in a training database or with a supervised account before handling live records.
- Enable the module from Settings > Manage Modules and grant catalog-management permissions to the responsible team.
- Create categories and tags first so every application can be grouped consistently.
- Add the application profile with a plain-language purpose, supported audience, screenshots, and support contact notes.
- Upload or link the first version, including a changelog and any installation prerequisites.
- Set visibility rules, test the listing as a normal user, and verify the download log records the event.
Standard Operating Procedures
These SOPs describe the routine operating pattern. Your company policy may add approvals, attachments, or segregation-of-duties controls.
Publish a new application
- Confirm the package source is official, scanned, and approved for distribution.
- Create the catalog record with a clear name, category, summary, screenshots, and support details.
- Add the initial version with release notes, package link, platform requirements, and installation notes.
- Apply visibility rules and open the listing with a test user before announcing it.
Release an update
- Open the existing application record and add a new version instead of overwriting the old release.
- Summarize fixes, new features, breaking changes, and any required user action.
- Mark the intended version as current when it is ready, keeping old releases traceable when policy allows.
- Review early download activity and ratings after publication.
Retire or hide an application
- Confirm there is a replacement path or a business reason to stop distribution.
- Update the description with retirement guidance and support instructions.
- Remove public visibility or restrict access to administrators only.
- Keep historical download logs intact for audit and support investigations.
Industry Notes and Good Practice
- Treat the catalog as a software-release control point. Users should not install business tools from chat attachments or untracked shared folders.
- Write release notes for non-technical readers first, then add technical details for administrators.
- Keep screenshots current. A mismatched image can make beginners think they opened the wrong application.
- For regulated environments, keep the download log and version history as part of change-management evidence.
Controls, Data Quality, and Review Checklist
Use this checklist during onboarding, monthly review, and process audits.
- Every listing has a clear owner, support path, category, and intended audience.
- Every downloadable package has a version, release date, changelog, and official source.
- Visibility rules are tested with at least one non-admin account before announcement.
- Deprecated apps are hidden or labelled so users do not install old tools by mistake.
Related ERPat areas
FAQ and Troubleshooting
Why can I see an app but not download it?Your role or tenant may have view-only access, or the current version may be restricted. Ask an administrator to check the visibility rule.
Should I overwrite an old installer link?No. Add a new version whenever the package changes so the history remains traceable.
Can public users see the catalog?Only listings intentionally exposed by the module rules should appear publicly. Test public access before sharing links.
What should a beginner read first?Start with the application summary, screenshots, version notes, and installation requirements before clicking download.