Skip to main content

​
Publish & Deploy

​
Sources

Docs: Propose Web App: Parable staff publish and deploy a Version. In a Workspace, a Delivery that waits shows Update available. Publish & Deploy is the staff action that accepts approved Changes, creates one Version, and deploys that Version to the selected Workspace audience. The review decision and target audience are visible before approval. When a Workspace line publishes a Version, everyone reading that Parable hears it, and nobody is moved: the Page stays on the Release on screen until the person opens the new one. A notice says v1.84 is ready with Open v1.84 once the new Version’s stored Plots can be served. A minor Release, or a Release with no Pipeline Plot, can be served at once. A major Release with a Pipeline Plot can be served after its first Refresh completes. Until then, readers on Newest stay on the earlier Release that has data (Reports). While the Parable’s Pipelines are off, no Refresh can run, so a notice says v2.0 has no data, and this Parable’s Pipelines are off. with Open v2.0. A save of a Preference never publishes: every Preference is Live (Preferences). A Release stores the line’s Default rows, and a copy takes them when it Publishes that Release (A Delivery applies itself). Publish and Deploy remain separate actions. Publish moves reviewed Changes forward on one Parable line and creates a Version. Deploy changes which Workspaces receive an already published Version; it does not create another Version. Use Publish & Deploy only when both effects are intended. A Workspace publication makes a reviewed Version current on that Workspace line. Only Parable staff can widen the audience by deploying to another Workspace. Changing the selection in Deployments prepares the audience for the next publication. That selection alone does not deploy a Version.

​
Bare admin

A Deploy, a Revoke and a Retract need two things: Build Parables from Admin, and Publishing or Primary on the Parable’s source line. A person who holds Build Parables from Admin and no seat on the line is refused with PA-AU-019. A person with Publishing or Primary on the line, without Build Parables from Admin, is refused with PA-AU-019 too. They read “Only Parable staff can deploy this Parable. Ask Parable staff to do it.” Revoke and Retract answer the same way. A platform administrator who holds the admin permission itself needs neither. They hold Primary on every Parable line, in every Workspace they can open, and every permission, seat and Policy check admits them. A narrower permission, such as Build Parables from Admin, does not do this. In View as, they see what the previewed person sees. When another person previews them, the preview shows only the seat they hold on the line. The act still records the person who acted. When only this rule admitted an act, it also writes an admin.parable_exemption audit event. The event names the person, the line, the act, and the check that their own seat failed. The rules of the Parable itself still apply to them: the stage of a Patch, a line that has published no Release, a copy whose Forking is off, and a Parable whose Pipelines are off.

​
Move a handle between Piece kinds

One Release can delete a Piece and give its handle to a new Piece of another kind. For example, delete a Plot named concepts and add a Pane with the handle concepts in the same Patch. Publish applies the deletions before it adds or changes live Pieces. A Delivery applies the same rule to a composed copy. Two live Pieces cannot share a handle in one composed Parable. Pages, Packages, Panes, Plots, and Reports share this namespace. Prepare refuses a true conflict and names the handle and both Pieces. Rename one Piece or delete one Piece in the Patch, then Prepare again. Publish checks the same rule.

​
Visible

A deployed Parable reaches a Workspace’s people only while that Workspace’s Visible switch is on. Visible adds the Workspace to the Participants list, at Pinging: every member, now or later, can read the Parable and comment on it.
  • A Parable starts with Visible off. Deploying it delivers the content, and its Report plans run on each Workspace’s data, on their schedule and after their sources, but the Workspace’s members, its administrators included, do not see it.
  • While it is off, only people the Workspace seated by name, and members who are Parable staff, see and open it there.
  • Turning a Workspace on adds it at Pinging. Turning it off takes that away; the Parable stays deployed, and nothing it delivered or changed locally is lost.
Parable staff set Visible for every Workspace at once, or for each Workspace on its own. A demo Workspace’s copy of a Parable Directory or Platform Parable is always Visible (Demo Workspaces).

​
Add and remove Workspaces

Deploy adds Workspaces to a Parable’s audience. Revoke removes Workspaces from it. Neither one publishes a Release. Each one adds a dated Rollout to the Parable’s history. Both need Parable staff who hold Publishing or Primary on the source Deployment. A Deploy’s list replaces the audience. A Workspace that the list leaves out loses the Parable. Use Revoke to remove a Workspace on purpose: only Revoke also cancels the Workspace’s Deliveries and removes the seats the Deploy gave it. rootRefId names the source Deployment. It is the root_ref_id of the Parable in workspace.parables, in the Workspace that made the Parable. Deploy and Revoke refuse a copy’s rootRefId. Reading a Rollout’s audience (list_rollout_targets) also needs the staff permission admin.tenant.view. Deploy and Revoke do not.

​
Add Workspaces

Through the API or MCP:
  1. Read the Parable: GET /api/parable/authoring/primaries/{rootRefId} (check_parable_state). Keep its currentRolloutId, its currentVersionId, and its workspaceId, which is the Workspace that made the Parable.
  2. Read that Rollout’s audience: GET /api/parable/authoring/rollouts/{currentRolloutId}/targets (list_rollout_targets). Keep the tenantId of each row whose selection is not not_selected.
  3. Deploy. Send those Workspaces and the new ones as selectedWorkspaceIds.
Do not put the Workspace that made the Parable in the list. It has the Parable already. Do not use all to add one Workspace: all sends the Parable to every Workspace you can publish into. When no Workspace other than the one that made the Parable can get it, a Deploy with all is refused with PA-AU-016 and the reason no_other_workspace, and changes nothing. expectedCommitId is the Release that Deploy sends. A Publish that lands between your read and the Deploy does not change it, so Deploy never sends a newer Release that you did not choose. It can be an older Release that is not retracted. A Workspace in the list that runs a newer Release then gets a Delivery of the older one. When the list holds a Workspace that Deploy cannot send to, Deploy refuses with PA-AU-016 and changes nothing. The answer names each of these Workspaces and why, in its sentence and in details.workspaces, with one reason each. It gives each Workspace’s workspaceId. It gives the name too when you hold admin.tenant.view. A list with the same Workspaces and the same Release as the current Rollout changes nothing, and Deploy answers PA-AU-021.

​
Remove Workspaces

In Admin, open the Parable, then Collaboration > Deployments. Under Visible, choose Remove from Workspaces. The dialog lists the Workspaces that the current Rollout reaches. Choose the Workspaces that lose the Parable, say why, and confirm. Through the API or MCP:
  1. Read the Parable: GET /api/parable/authoring/primaries/{rootRefId} (check_parable_state). Keep its currentRolloutId. With no currentRolloutId, no Workspace has the Parable, and there is nothing to remove.
  2. Read that Rollout’s audience: GET /api/parable/authoring/rollouts/{currentRolloutId}/targets (list_rollout_targets). The audience is every row whose selection is not not_selected. This read needs admin.tenant.view, because each row names a Workspace. Revoke itself does not need it.
  3. Revoke. Send the audience without the Workspaces to remove as retainedTenantIds, and currentRolloutId as expectedRolloutId.
What Revoke does to each removed Workspace:
  • Deliveries that are on their way to it are cancelled. A Delivery that the Workspace already applied stays applied.
  • The seats the Deploy gave it are removed: the Workspace at Pinging and the Workspace Administrator Role at Primary. Seats that name a person stay.
  • Its copy stays, with its Patches and Releases, but it no longer opens in the Workspace. Deployments no longer lists it.
  • A later Deploy that names the Workspace gives it the Parable again.
Revoke refuses:
  • a Platform Parable. It reaches every Workspace, so use Visible to hide it in one Workspace.
  • an expectedRolloutId that is not the current Rollout. A Deploy or a Revoke changed the audience after you read it. Read it again.
  • a retainedTenantIds that keeps every Workspace (nothing to remove), or that names a Workspace outside the audience. Revoke cannot add a Workspace.
These do not remove a Workspace: Pocket on the copy pockets the Workspace’s Deployment, a staff delete acts on the copy in your own Workspace, and Visible off only hides the Parable from the Workspace’s people.

​
A copy that a later Deploy left out

A Deploy whose list leaves out a Workspace takes the Parable away from that Workspace’s people, but it does not clean up the copy. The copy keeps the seats the Deploy gave it. A Delivery that was on its way keeps its state, such as Update available, and never moves on, because its Rollout is no longer current. Deployments does not list such a copy. Revoke cannot reach the copy, because it is not in the current audience. To clean it up, Deploy the Workspace back into the list, then Revoke it. The Revoke cancels every unfinished Delivery of the copy, the old one included, and removes its seats. The Deploy can apply its Release to the copy before the Revoke runs. An applied Delivery stays applied, but the copy still opens for nobody in that Workspace.

​
Platform Parables

A Platform Parable is deployed to every Workspace, including Workspaces created later. It is the only kind of Parable whose Plots other Parables can read (Parable Pool).
  • Parable staff turn Platform on for a Parable. Every Parable starts with it off. Only a Parable made in a Workspace that Parable runs, such as Dogfood, can become a Platform Parable. For a Parable made in a customer Workspace, the switch is refused.
  • Turning it on names no Version. It deploys the newest published Release to every Workspace, including Workspaces made later. A Parable with no Release yet deploys at its first Publish.
  • Every Publish of a Platform Parable is also a Deploy to every Workspace. Nobody picks a Version or an audience, and no Workspace stays behind. To publish it, a person needs the same seat as for a Deploy: Parable staff who hold Publishing or Primary on the Parable. A person who is not Parable staff and publishes it is refused with PA-AU-019, reads “Only Parable staff can deploy this Parable. Ask Parable staff to do it.”, and the Release does not move. A Deploy of it to fewer Workspaces is refused. A Workspace that is deleted while a Publish or a Deploy runs is not in its audience, and the others still get the Release. The Publishing panel shows no audience choice. Above the publish action and in Deployments, above the Visible list, it says: “Platform Parable. Every Release you publish goes to every Workspace, including new ones. Visible decides where people see it.”
  • Visible stays the only control for each Workspace. While a Platform Parable is not Visible in a Workspace, it gives nothing there, also to the Parables that read it: they read its Plots as empty tables.
  • While other Parables’ published Versions read it, it stays a Platform Parable. Turning it off, archiving it and deleting it are refused, and the refusal names those Parables. Publish them without their reads of it first.
  • A Retract of one of its Releases is refused while another Parable reads that Release: the Version of that Parable that a Workspace reads now pinned it. The refusal names those Parables. Publish them again so they read a newer Release, then retract it. An older Version that no Workspace reads does not count.
  • Turning it off keeps what every Workspace received, and the next Deploy chooses its Workspaces again.
  • In a Workspace, a Platform Parable is listed under Platform in the sidebar, with Premises, Providers, People and Protection. In Admin, it is listed under Platform too, at the bottom of the sidebar, above Parables for Admins. Choose it there to open it in the Admin editor.
  • It is also a view in the Parable’s header of every Parable, after Pieces, Problems and People, for each person who can read it (Ponder). The view opens the Platform Parable in the Parable’s place, at the width of that column. A reader can make the column narrow, so make each Page work at S (390 px wide) as well as at the wider sizes.

​
Demo Workspaces

A demo Workspace is a Workspace that Parable fills with a generated company. Every demo Workspace runs each Parable whose Publisher is Parable Directory, and each Platform Parable, so customers can see those Parables with data. Nobody deploys to a demo Workspace by hand (PARABLE-7232).
  • Every Deploy, Publish & Deploy and Revoke of such a Parable keeps every demo Workspace in its audience. The Workspaces that staff pick do not change this.
  • Each Publish of a Parable Directory Parable sends its new Release to every demo Workspace. Customer Workspaces keep the Release they run until staff Deploy it. A Platform Parable’s Publish already reaches every Workspace.
  • A demo Workspace’s copy is always Visible. A Deploy mints it Visible and turns a hidden copy Visible. Visible off for that Workspace is refused with “A demo Workspace always shows Parable Directory and Platform Parables.” Visible off for every Workspace leaves the demo Workspaces on.
  • The Release applies itself in each demo Workspace when its conditions hold. Then Parable runs a Refresh there, on that Workspace’s demo data, once for each Release. History names it Refresh by Parable. A copy whose Pipelines are off, whose Refresh already runs, or that has no Plots starts none. Its next scheduled Refresh or the next Publish runs it.
  • A demo Workspace that is made later joins the newest Rollout of each such Parable, with a Visible copy. The copy applies a Release at the Parable’s next Publish.
  • A Parable that leaves the Parable Directory, and is not a Platform Parable, leaves this rule. Its demo Workspaces keep their copies until a Deploy leaves them out.

​
Platform copy participation

New copies of composed Platform Parables seat Parable staff at Primary and Publishing. Workspace members hold Pinging while Visible. A Workspace Administrator Role alone gives no Primary or Publishing on these copies. Member actions follow the copy’s own Policies, which arrive with Releases. Existing copies retain their previous participation until a separately approved migration enrolls them. Repeated Deploy does not perform that migration. On an enrolled copy, turning Platform off restores still-valid previous participation without changing its selected Release or local work. See Primary for the participation and Support boundaries.

​
When a Delivery arrives

A newly delivered Parable can be read in Peeking before the Workspace pulls it. It uses the delivered definition and the Workspace’s existing Policy checks. Pull brings that delivery into the Workspace’s own change review; it is not a prerequisite for viewing the delivered app. On a new non-Platform composed copy, the Workspace Administrator Role receives Primary only when no Primary already exists. Named participation remains unchanged. On a managed composed Platform copy, Parable staff hold Primary and Publishing. Existing unenrolled copies retain their previous participation until the separately approved migration. A person with Primary or Publishing can pull and publish a Delivery when the other required permissions and checks pass. While Visible, Workspace members hold Pinging. The copy’s Policies determine their allowed actions. A Workspace’s copy is locked. Its people, and Ponder working for them, cannot start Changes on it, save a Piece, change a schedule, or publish a set of Changes of their own. They can pull a Delivery and publish it, save Preferences, run Reports and comment. Parable staff open one copy to changes with Forking (Staff Settings). A copy of a Platform Parable is never forked. People in a forked copy can add, change and delete any Piece, the Pieces that its Release supplies included. A later Delivery keeps the copy’s own changes and brings every other change of the Release. A Piece that the copy deleted stays deleted. When the Release changed a Piece that the copy also changed or deleted, Prepare shows a conflict for that Piece, and the person who prepares the Pull chooses the copy’s side or the Release’s side. Only the Release’s side brings a deleted Piece back (What a forked copy may change).
Deploy can widen who receives a Parable. A Workspace role, model choice, or Power cannot turn an unavailable Deploy into an authorized action.

​
A Delivery applies itself

A Delivery applies itself to a Workspace’s copy when its conditions hold, so a Workspace with no changes of its own takes each Delivery without anyone doing anything. A locked copy gains no changes of its own, so a copy that has none keeps taking each update this way. Right after Deploy, or Publish & Deploy, the platform Pulls, Prepares and Publishes the Delivery in that Workspace, and the Version names the Parable Platform as its publisher. It does this only when all of these hold:
  • The copy is locked. A forked copy never takes a Delivery by itself (Forking).
  • The Delivery reconciler has checked the Delivery. It compares the Release’s content with the hash that Publish sealed. It checks a new Rollout within about 15 seconds, and the platform waits up to three minutes for it.
  • The Workspace has published no Piece change of its own since the Version it last took. Preferences do not count, because every Preference is Live.
  • Nobody in the Workspace is reviewing another Delivery.
  • Every Preference someone saved still fits the delivered Panes.
  • Prepare finds nothing blocking: no conflict, no Plot gate finding, no Warnings & Errors.
  • Someone in the Workspace who holds Primary on the copy may run its Reports. Nobody in the Workspace acts, so the platform borrows Primary, as scheduled Reports do: its Plots are planned as that person, and Primary decides new Pages, new Panes and Policy changes.
Otherwise the Delivery waits, marked Update available, until a person with Publishing or Primary on the copy Pulls it and Publishes it. The platform does not try again later, so a Delivery that missed the three minutes waits for a person too. Until then, the Workspace’s readers keep its current Release and cannot open the delivered one. Open readers hear either way. An applied Version reaches them as Updated to v1.84 once its stored Plots can be served; a Delivery that waits makes Update available appear for the people who hold Publishing or Primary on the copy. A Workspace with Visible off applies the same way, and only its seated people hear about it. While Visible is off, a Version with Plots still waits for a person. An applied Version starts no Report. Its readers keep the previous Version until the Parable’s next scheduled Report, or a Refresh, produces the new one’s (Reports). In a demo Workspace, Parable runs that Refresh at once (Demo Workspaces).