Eolas · Togra Log in →
Eolas · Using Togra

Portals — who gets a login and what they see

Last verified 17 Jul 2026


# Portals — who gets a login and what they see

A production involves dozens of counterparties who need to see — and sometimes submit — a slice of the production's data: a supplier chasing a PO, an agent submitting for a role, an auditor working the DAC's books, a funder officer checking drawdowns. Togra gives each of them their own scoped login instead of email attachments and spreadsheets.


The three doors

Everyone arrives at one sign-in page — the three doors are tabs on it, and Togra remembers which one you used last time (the old /portals address still lands there):

  1. The producer app — the full Togra platform, for the production company's own team (with personas as the presentation lens).
  2. The Cast & Crew portal — self-service for the freelancers on your productions: complete onboarding, submit weekly timesheets and expenses, keep availability current, acknowledge policies, and — for skills-plan participants — keep training journals. Freelancers can carry one portable profile across every company that engages them; onboarding invites offer the account with the details they just entered already in place.
  3. The stakeholder portal — per-project, role-scoped rooms for outside counterparties, invited by the producer. One login can hold grants on several projects (and from several companies); each grant opens the room its role defines.

How stakeholder access works

  • The invite is the grant. You mint an invite from the surface that owns the relationship (the audit pack for an auditor, the funder application view for a funder officer, the casting surfaces for an agent). The link is single-use and expires if unused; accepting it proves the email address. Revoking the grant closes the door immediately.
  • Scope is per project, per role. A grant shows one project through one role's room. What each role sees is a deliberate whitelist — internal ratings, notes, other parties' terms and your cost data stay on your side, and the sections below say what's excluded so there's no guesswork.
  • Submissions are staged; verdicts are theirs. Anything a stakeholder sends in — a supplier invoice, an agent's casting submission, a co-producer document — lands in a producer review queue for you to accept or reject; nothing external writes into your books directly. The one thing that records immediately is a counterparty's own decision (an agent confirming an audition, a broadcaster accepting or rejecting a sent deliverable) — that verdict is their data, and every rejection carries a note you see, so there are no silent outcomes either way.
  • Real account security. Portal accounts carry the same protections as producer accounts: verified email, optional two-factor authentication, and login lockouts.

The rooms, role by role

Finance stakeholders — lender · S481 broker · equity investor · completion bond. Each party sees their own position on the production — their instrument, drawdown schedule and status — plus a document data room. They see their own money, not each other's terms.

Casting agent. The open roles on the granted project, submission of clients for those roles (each submission is stamped with the agent's identity — no impersonation), audition slots to confirm or decline, and offer status with LOI dates. A recorded pass shows as "not proceeding" straight away rather than going quiet. Agents never see fees, internal casting notes or other agents' submissions.

Writer / author. A producer-curated room: you choose at share time exactly which records the writer sees. It can carry their options and reversion dates (with expiry flags), draft history and step-deal schedule, their contracts with signing built in, and their Article 19 transparency statements with a query thread. The writer's own money — option fee, step fees, contract fee — shows, because the writer is the party to it.

Supplier / vendor. Their purchase orders (without your cost codes), staged invoice submission straight into your AP review inbox (with duplicate-number flagging on your side), their ledger position with remittance history, and an insurance/certificate register with expiry tracking. Bank details are never readable or editable in the portal — account changes only happen through a producer-initiated re-onboarding, which is what keeps invoice-redirect fraud out.

Co-producer. The co-production structure and splits, their own drawdown schedule line by line, the rest of the finance plan as one aggregate (partners aren't scored against each other), and quarterly reporting history — alongside the existing document corridor between the companies.

External auditor. Read-only books for the project's DAC: trial balance, drill-through to journals, the project ledger, period-lock status, the filing-engagement summary and CSV exports. Read-only is structural — the auditor's login realm simply has no write surfaces. (Distinct from the external filing accountant, who is an invited group member with a writable persona — they prepare and file; the auditor inspects.)

Funder officer. The registry-backed funder view: their organisation's applications, awards, drawdown tranches and the post-award checklist on the granted project — scoped to their funder, so a Screen Ireland officer never sees the broadcaster's money or vice versa.

Chaperone / tutor. The child-performance room: licences, rostered days and a daily log with live working-hours breach flags, so compliance for minors is visible to the person on the floor responsible for it.

Service principal. On an inbound service production, the foreign principal's exec sees spend against the approved Irish cap by department — the same figures as the producer's cost statements, one calculation engine — their fee schedule and invoices, issued cost statements to accept or query (a query needs a note the producer sees), variance explanations, the FX basis and the S481 certification status as a progress strip. Supplier-level spend lines and DCCS correspondence never cross.

Broadcaster — delivery. The commissioning broadcaster's delivery contact sees their deliverables checklist on the production — every item with its spec, due and sent dates — and can accept or reject items the producer has marked sent (a rejection requires a note the producer sees immediately). Accepting stamps the sign-off date; files travel only through the producer's existing secure-share links. Each broadcaster sees only their own list, never another buyer's on the same production.

Producer-side hubs that ride the same rails

Two personal dashboards for people on your own team follow the same "just my slice" idea, inside the producer app:

  • The skills portal — participants keep journals and task sheets from their Cast & Crew login; supervisors and mentors get a standing sign-off and feedback channel; the SDO's hub queues every blocker with a link to the page that clears it; and read-only progress links can be shared with Screen Ireland for a limited window. See the Skills Development Plan.
  • The HoD dashboard — a Head of Department's personal hub: their department's labour burn (from approved, paid timesheets, per currency) and spend requests that route into the producer's approvals inbox.

Why it's built this way

Every portal exists to replace an email thread that leaked too much or recorded too little. The scoping is the feature: each counterparty gets a live, always-current view of exactly their slice — and you get submissions arriving structured, reviewed, and attributable instead of loose attachments.


The By role section has a short guide per portal role — what you see, what you never see, and how to work the room.

Sources

  • · portals.php (the entry door) · worker.php (Cast & Crew) · the stakeholder portal rooms
  • · lib/stakeholder_auth.php + the per-role room libraries (finance / casting / writer / supplier / co-producer / auditor / funder)
  • · docs/PORTALS-SPEC.md (shipped state, 2026-07-17 — Tiers 1 + 2 complete)