# Corporate portal

> The employee-facing intranet - a newsroom with a real editorial pipeline that starts as rows on a sheet, a tagged media gallery, an events calendar, the org directory, and a rewards programme whose points are ledger balances behind a working shop

Source: https://aipril.dev/docs/solutions/corporate-portal

Most intranets are a content management system with an org chart bolted on. This one is five business
processes, a ledger asset, a shared sheet and a set of catalogues, presented as one employee-facing
surface.

So its parts behave like the rest of your company's systems instead of like a website.

## The landing page

The screen people open in the morning answers "what do I need to know and what do I need to do",
instead of being a second newsroom:

- **One featured story**, with a way into the newsroom
- **Upcoming corporate events**
- **A featured benefit**
- **Recently recognised colleagues** - who was recognised and why, so the company is visibly
  celebrating contributions instead of displaying point totals
- **Gallery highlights**
- **A poll**
- **The employee's own requests** - what they are waiting on

## News, from an idea on a sheet to a published post

The editorial pipeline starts **before a story exists**.

**Story ideas live as rows on a shared [sheet](https://aipril.dev/docs/spreadsheets.md)** - drafted, triaged, assigned,
prioritised, with whatever columns your editorial team actually argues about. It is a spreadsheet, so
an editorial meeting is a normal meeting instead of a tool-adoption exercise.

When an idea becomes a story, **the row keeps up by itself**: the sheet's row reflects what happened
to the post it turned into, because both are on the same platform and not in two systems somebody
reconciles.

Then the post moves through a **publication lifecycle** - drafting, review, approval, release - as a
real [process](https://aipril.dev/docs/processes.md), with named statuses, permitted transitions and who may perform each
one, instead of a "published" checkbox with an honour system around it.

- **Nothing appears in the newsroom that has not been through it**, which is what makes the newsroom
  a source, not a noticeboard.
- **A cover image is part of the lifecycle**, not an upload somebody remembers to do.
- **The editorial board itself** - the kanban editors work stories on - lives in the administrative
  application, so the portal never doubles as an editorial console.

## The gallery of the company's own life

Company photographs - offices, teams, events - **filterable by tag** and viewable in **several
layouts**.

Underneath, a photo is a record in a gallery process carrying tagged image attachments, and **only
published ones are shown**. So the gallery has the same moderation story as the newsroom: a picture
is in it because somebody released it, not because somebody uploaded it.

## The events calendar

Upcoming corporate events on a **day-picker strip** - range-selectable, with dots on days that have
something, a Today button and paged navigation - above a **horizontal reel of event cards** linked to
the strip, so picking a day filters the reel.

The events themselves are a shared process filtered to published, and the administrative side - the
events board where they are created and scheduled - is in the administrative application.

## The org directory

Who is who, who reports to whom, and which unit somebody belongs to - read from the platform's
**shared org structure** instead of from a copy the portal maintains.

That shared structure is the same one approvals route through, the same one an
[AI employee](https://aipril.dev/docs/ai-organisation.md) is a member of, and the same one price approvals and project
roles resolve against. One org, not one per system. See
[AI organisation](https://aipril.dev/docs/ai-organisation/people.md).

## Rewards: a real programme, not a points widget

It is three things at once.

**A catalogue.** What can be redeemed, with its cost, its availability and its rules - maintained as
ordinary [master data](https://aipril.dev/docs/master-data.md) by an administrator, not hardcoded.

**A ledger.** Points are an asset in the platform's [ledger](https://aipril.dev/docs/ledger/what-you-can-do.md), with
accounts per employee and double-entry postings - not a number incremented in a table. So:

- **A balance has a statement behind it.** "Why do I have 340 points" is answerable line by line.
- **An award is a posting** made by a recognised process, with an actor on it.
- **A mistaken award is reversed**, not edited away, so the record of what happened survives the
  correction.
- **The totals reconcile.** What was awarded across the company and what employees hold are two views
  of the same postings rather than two counters that drift.

**A shop.** Browse the catalogue, **build a cart**, submit a redemption request, see your own balance
and your own request history - all against real data, not an illustrative screen.

And a redemption is a **process**: the request is submitted, approved, and fulfilled, with each step
recorded. Granting points, approving a redemption and fulfilling it are administrative surfaces in the
administrative application; the employee sees the shop.

## Requests go somewhere

A request raised on the portal lands in the [service desk](https://aipril.dev/docs/solutions/service-desk.md) - triaged,
routed by category and tracked against an SLA, with replies reaching people in Telegram or email.

## Employee surfaces and admin surfaces are separate applications

A deliberate rule, not an accident of layout: **an authoring or administration surface belongs in its
own application**, reached through the switcher in the navbar.

So the editorial kanban, idea-board analytics, the events board, and the whole benefits
administration - catalogue, grants, redemption approval and fulfilment - are their own application.
The portal provides the shared processes and the shared sheet; the administrative application consumes
them.

The result is a portal that stays a portal, and an admin console that does not have to pretend to be
one.

## What it is made of

| Part | Built as |
|---|---|
| News | A publication process, plus a shared sheet of story ideas |
| Gallery | A process whose records carry tagged image attachments |
| Events | A shared process, employee view filtered to published |
| Benefits | A ledger asset, a catalogue, and a redemption process |
| Requests | A service-request process, consumed by the service desk |
| Pages | The platform's own widget catalogue and theme |

Every one of those is an artifact you can open and change - see
[Applications](https://aipril.dev/docs/apps/under-the-hood.md). The portal is a starting point that happens to work, not a
fixed product.