# Adding a business screen to the back office

> Many stores run with a spreadsheet permanently open beside the back office: supplier tracking, per-customer budgets, commissions, bookings, pre-dispatch checks. That is exactly the kind of need a custom admin screen removes.

- Source canonique : [https://allaux.fr/en/modules/ecran-metier-dans-le-back-office](https://allaux.fr/en/modules/ecran-metier-dans-le-back-office)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

These requests always share the same shape: business information exists, it relates to products, customers or orders, and the admin shipped with the platform can’t display it. For want of anything better it is kept alongside, in a file nobody truly keeps in sync.

A business screen puts that information back where it belongs. In practice it takes the form of a tab in the admin menu, with a filterable, sortable list, a detail view, and usually an export. Access rights lean on the profiles already defined in the store, which avoids inventing a second permission system.

## How I approach this kind of work

I lean on the platform’s admin mechanisms rather than on a standalone page. On PrestaShop that means an admin controller declared by the module, with its menu entry, its permissions and its actions, giving a screen consistent with the rest of the back office. On WordPress it goes through an admin page registered by the extension, using the native list component when the data suits it.

That choice has an important practical consequence: the screen inherits access control, breadcrumbs, translations and the platform’s look. A page built beside the admin system is quicker to write and far more expensive to live with, because it ages separately.

I pay particular attention to volume: a business list always ends up holding far more rows than expected. Pagination at database level, filters that rely on indexes, and an export that doesn’t load everything into memory at once.

## Factors that affect the estimate

- **Read-only or data entry** — A screen that displays is simple. A screen that writes needs input validation, permission handling and an audit trail.
- **Where the data comes from** — Data already in the store is read directly. Data from an outside system adds a synchronisation to design.
- **Volume and filters** — A list of a few hundred rows and one of several hundred thousand aren’t built the same way.
- **Multi-store and multilingual** — Both multiply the cases to handle in filters, permissions and exports.

## Related pages

- **Adding a product or order field** — When the need is one extra piece of data rather than a whole screen. ([/modules/ajouter-un-champ-produit-ou-commande](/modules/ajouter-un-champ-produit-ou-commande))
- **Scoping a module requirement** — The questions to settle before drawing the screen. ([/modules/cadrer-un-besoin-de-module](/modules/cadrer-un-besoin-de-module))
- **Task automation** — When a screen isn’t enough and the processing must run on its own. ([/services/automatisation](/services/automatisation))
- **Bespoke development** — The general frame for this kind of work and how it runs. ([/services/developpement-sur-mesure](/services/developpement-sur-mesure))

## FAQ

### Will the screen be visible to every administrator?

No, it relies on the profiles and permissions already defined in the store. A profile can view the list without editing, or not see the tab at all.

### Can an existing spreadsheet be replaced without losing history?

Yes, provided the file is usable: an initial import brings in existing rows. That is a step in its own right, and its difficulty depends on how regular the file is, not on its size.

### Will the screen survive a platform update?

If it uses the intended admin mechanisms, it follows routine releases without intervention. A major platform version change does call for a check, as with any module.

### Can the displayed data be exported?

Yes, and it is nearly always asked for. The export is designed in from the start, because adding one afterwards to a large list often means revisiting how the data is read.