Appearance
Your workspace in the portal
Everything you do on the bus happens in a workspace: a vendor workspace to prove your own apps, or a publisher workspace for a newsroom. RND creates your organisation's first workspace when it approves your access request. A publisher organisation also gets a workbench beside it, to grade its own in-house apps.
Every workspace, vendor or publisher, holds synthetic content only. It's a test environment: never publish real stories, sources or media to it.
Join your workspace Available now
- Sign in. On approval you get two emails: the decision, and a temporary password. Sign in to the portal, choose your own password and set up an authenticator app. Multi-factor sign-in is required. If you already have a portal account, sign in as usual.
- Accept the invitation. The portal shows the invitation to your workspace at the top of the page. Press Accept. The invitation works once, only for the email address it was sent to, and expires after 14 days. If it has expired, ask an owner or admin of the workspace to renew it. If the first owner invitation of a new workspace expires before anyone has joined, ask RND through Ask RND.
Whoever accepts the owner invitation is the workspace's first owner. From then on, the workspace's owners and admins bring in the rest of the team themselves: see Your team.
What you see Available now
Every page is about the workspace you're in. The menu follows the order you use it in: Monitor, then Set up (Apps and credentials, Consumer connections), then Test (SOM fit check, Playground, Test runs, Results statements).
| Page | Shows |
|---|---|
| Overview | Your first steps checklist, then your workspace's accepted, rejected and duplicate messages over 24 hours and 7 days, and its most common rejection rules |
| Activity | The gateway's decisions on your workspace's messages, with the rules behind each rejection. Never payloads |
| Story timeline | Your workspace's stories and their messages in order, kept 7 days |
| Routing map | For each message type, which connections publish it and which consumer connections receive it, with the organisation that owns each. See Routing map |
| Playground | A dry run against your workspace's story state, and who would receive the message. Nothing is stored or sent. Developers can also publish for real as one of their apps |
| SOM fit check | Paste one of your own stories and see how it maps onto SOM 1.0, with a starter message for the Playground. Nothing is stored. See SOM fit check |
| Apps and credentials | Your organisation's apps and which of them are connected to this workspace. Developers create producer apps, connect them and manage their secrets: see Credentials. A consumer or skill app shows as connected while it has an active consumer connection; its connections and their secrets are managed on Consumer connections |
| Consumer connections | Your apps' queues for this workspace's messages: create, revoke and remove them, and get client secrets for the HTTPS pull API. See Consumer connections |
| Test runs | In a vendor workspace or your workbench: consumer scenarios and skill cases played into the workspace, graded case by case. See Test runs |
| Results statements | In a vendor workspace or your workbench: what your complete runs passed, to share with a publisher or by link. In a publisher workspace: the statements vendors have shared with your organisation. See Results statements |
| Notifications | Who in the workspace gets which emails. See Notifications |
| Team | Who is in the workspace and their roles. Owners and admins invite colleagues, renew invitations, change roles and remove people; anyone can leave. See Your team |
| Your house: vendors | In a publisher workspace: invite vendors, decide what their apps may publish or receive, and disconnect them. See Bring your vendors into your house |
| Coverage | In a publisher workspace: each app in your house against the message families, consumer scenarios and skill cases, from the results statements vendors share with you and your house's own traffic, with every gap named. See Reading the coverage matrix |
| Houses you're in | In a vendor workspace: join a publisher's house, connect your apps and get their secrets. See Join a publisher's house |
| Ask RND, What's next | A question, problem or idea for an RND engineer (Ask RND), and what RND is building |
Nobody outside your workspace sees its traffic or its stories: other vendors and publishers can't, nor can members of other workspaces. In a publisher's house, the vendors' connections show as counts: see Who sees what in a house. In the portal, RND sees the gateway's decisions (outcomes, message types and rule ids), never your payloads. The payloads themselves are held by the bus, in your story timeline, your consumer queues and the replay archive, for as long as Environments says.
Your team Available now
RND approves your organisation once. After that, your workspace's owners and admins manage the team on the Team page, under People in the side bar. Nobody needs to ask RND.
Roles. Every member has one role in the workspace. Each role can do everything the role before it can.
| Role | Can |
|---|---|
| Viewer | See the workspace: its traffic, stories, apps and members |
| Developer | Create and connect apps and manage their credentials, start test runs and house rehearsals, make results statements |
| Admin | Invite colleagues and manage roles below owner, share results statements, choose notification emails, story ownership and house settings, see recent team changes |
| Owner | Invite owners and make or remove them, hand the workspace over, manage your organisation's identity providers |
The portal's API checks every role on every request; the page only hides what you can't do.
Invite a colleague. Press Invite a colleague, enter their email and choose a role. Admins invite viewers, developers and admins; only owners invite owners.
- The invitation works once, only for that email address, and expires after 14 days.
- Someone new to the portal also gets a sign-in: an email from the portal's sign-in service with a temporary password. The invitation email tells them to sign in and accept.
- If the invitation email can't be sent, the page says so and gives you the sign-in link to pass on. The link alone lets nobody in: they still sign in with the invited email address and accept there.
Look after invitations. Owners and admins see every open and expired invitation, and those accepted or revoked in the last 30 days.
- Resend an open invitation: up to 3 emails per invitation, and renewing starts the count again. Someone who hasn't signed in to the portal yet also gets a new temporary password.
- Renew an expired invitation: it works for another 14 days and is emailed again.
- Revoke an open or expired invitation: it stops working at once.
- A workspace has at most 20 open invitations at a time, and at most 50 invitations made or renewed in 30 days. Ask RND if you need more.
- Only owners resend, renew or revoke an invitation to become an owner.
Manage members.
- Change a role. Admins change roles up to admin, including lowering their own. Only owners make someone an owner or change an owner's role. Nobody can raise their own role.
- Remove a member. Admins remove members below owner; owners can remove owners too. The person loses access to the workspace at once. Their portal sign-in stays, for any other workspaces they're in.
- Leave. Any member can leave from their own row. An owner or admin can invite you back.
- Hand the workspace over. An owner chooses Hand over ownership on another member's row: that member becomes an owner and you become an admin, in one step. To share ownership instead, make them an owner and stay one too.
- At least one owner. A workspace always keeps an owner. The last owner can't leave, step down or be removed until someone else is an owner.
Audited. Every invitation, renewal, role change, removal, departure and hand-over is recorded in the workspace's audit log, with who did it and when. Owners and admins see the recent team changes at the bottom of the Team page.
Your workbench Available now
A publisher's workspace is its house: the shared bus its newsroom and its vendors' apps run on. Test runs inject messages, so they never run in a house. Your own systems, such as your CMS or in-house tools, are graded somewhere else: your organisation's workbench.
- What it is. A vendor-type workspace that belongs to your organisation, labelled Workbench in the Workspace menu and on its Overview, where a note explains what it is for. It is named after your organisation, for example Daily Paper workbench.
- How you get it. It is created with your house when RND approves your organisation. Whoever accepts the house's owner invitation is its first owner too. Organisations approved before workbenches existed get theirs the next time an owner of the house opens the portal. The rest of your team joins it the way they join any workspace: by invitation.
- Same app, two connections. Apps belong to your organisation, not to a workspace. Connect an app to the workbench to grade it, and to your house to use it. Each connection has its own client secret, so revoking one never touches the other.
- Grade it. In the workbench, run the consumer scenarios or the skill harness on the Test runs page, then make a results statement from the passing runs. Share it with your own house, so its members see what passed, or with another publisher, as any vendor would.
- Its checklist. The workbench's Overview shows its own first steps: create an app, connect it, grade it with a test run, make a statement.
- Private to you. Only your organisation's apps connect to it, and only its members see it. Other publishers see a statement you share with them, never the workbench.
Several workspaces Available now
If you're a member of more than one workspace, choose one from the Workspace menu at the top of the side bar. The portal remembers your choice in this browser.
Known limits
- Apps RND registered for you in the bus configuration (see Apps RND manages for you) don't belong to a workspace, so their traffic isn't in your workspace's pages. Ask RND for their activity, or connect the app in your workspace yourself.
- A new workspace's first owner invitation, if it expires before anyone joins, needs RND: ask through Ask RND. Once someone has joined, the workspace's owners and admins look after its invitations.
- Apps, connections and credentials are yours, including the AWS role that reads a consumer queue directly (Read with AWS credentials).
- In a publisher's house, test runs don't run: they would reach your vendors' consumers. Grade your own apps in your workbench, and bring your vendors in as described in Bring your vendors into your house.