14 articles about Portals, in reading order.
Portals
A portal is a Studio app published at an address of its own, for people outside your organisation: customers, partners, the public. It reads only through Custom APIs, its visitors are portal users rather than platform users, and a rule on the table decides whose rows each one sees. We published the service desk sample, signed up as a customer, started a company, raised a case, and saw it from the inside.
Portals
Any Studio app can be published at a web address of its own. One panel says which app, which address, who can open it, and which screens a stranger may see before signing in; one tick puts it on the internet, and the same tick takes it off. We published the landing page sample and opened it on a desktop and a phone.
Portals
A public page drawn in the Studio: a hero with a picture under the accent colour, a band of three cards that wraps on a narrower screen, a pricing band whose cards line up, and a top bar drawn once and placed on every page. We opened the landing page sample in the designer and looked at how each part is made to work at every width.
Portals
A public site is several pages, one bar and a menu that follow you between them, and here a carousel and a second language too. We published the Orchard Lane sample, moved between its pages in English and Persian, and opened it in the designer to see the bar that knows which page it's on and the carousel that tells the page when to move on.
Portals
A public form that creates a record, from somebody with no account, protected from scripts by a moment's proof of work rather than a puzzle. We published the contact form sample, sent a message with a document from a private window, found it in the Messages app, and turned the one tick off to see the other side.
Portals
A portal that signs its visitors in gives each of them an account of their own: created on the portal, confirmed by email, with a name, a photo and a password they can reset. We published the members sample, signed up as a new visitor, tried to sign in too early, confirmed the address, changed the photo and the name, forgot the password, and found the account in the Admin Control Center.
Portals
A portal that signs visitors in has a sign-in page of the platform's own. You can draw yours instead, in the same app as the rest of the portal, and the password still goes only to the platform. We switched the members portal back to the standard page, then looked at how its drawn one is made: four settings on the portal, nine shared cards, and one function call.
Portals
A portal visitor can protect their own account with an authenticator app, from a page you drew. We turned it on for one visitor: scanned the code, saved the recovery codes, signed out, came back with a code from the app and then with a recovery code, and saw the account from the Admin Control Center.
Portals
On a portal, every visitor reaches the same table through the same Custom APIs, and each must see only their own company's rows. One rule on the table does it, for reads and writes alike, without a filter in any script. We put two companies' cases side by side, asked for the other company's case by its id, looked at the rule, and switched it off to see what it was holding back.
Portals
A visitor on a portal can raise a case. Can they correct it later, and send the document your team asks for? On the service desk they can now: change the subject and the urgency, add a note and attach a file, all in one save through one Custom API. The contract decides which fields a visitor may touch, and the file follows the same rule as the record.
Portals
A list of records on a portal page, without drawing the list: the platform's own grid, with the columns a view decides and the rows a Custom API returns. We put one on the service desk, picked its table, view and API in the designer, then added a column and watched it arrive empty until the API was told to return it.
Portals
One case, followed from both sides: a customer raises it on the portal, the support team answers it inside the platform, the customer replies with a photo, and the status says whose turn it is at every step. The customer and the team never share a screen, and each one sees only what is theirs to see.
Portals
On a portal, the people who look after a customer's account are the customer's, not yours. One of them starts a company, invites colleagues, decides who else may manage it, and removes people who leave, all from a page you drew. We watched an invitation go out, a colleague join and see the company's cases at once, and an Owner hand over the keys.
Portals
A portal starts at an address your installation gives it. Your customers would rather see support.northwind.com. You type the name, publish one DNS record the platform hands you, and press Check now; until the record is there, the name does nothing at all. We watched a domain go from a claim to an address, and a second one stay a claim.
