A Ploy CMS connection should link an editable record to the right public page and exclude content that is not approved. An external integration needs a separate defined action, account permission, and recovery path.
This guide uses Kings Landing's tested Ploy resource collection as the example. It explains what runs in the website, what an editor controls in the workspace, and what this publishing workflow does not establish about other integrations.
The example we tested
Our Ploy resource collection stores the hub, buyer guides, and own-site case study in PloyDB. The deployed website reads eligible records at request time. The same publication rule also supplies the cluster sitemap, related reading, and the public content index.
On 9 October 2026, three draft records produced public 404 responses and stayed out of the Ploy sitemap. After release, their public URLs returned 200 with the intended content and indexable metadata. The Blog linked to the hiring guide, Selected Work linked to the own-site case study, and the old agency URL redirected to the new hub.
No new site deployment was needed for those record releases. That result depends on the reader and credential already being deployed. New templates, source-code changes, and newly configured secrets still require a site publish.
Open the public hiring guide, the case study, or the Ploy sitemap to inspect the outputs.
Follow the data through the website
The input is an editable content record
Each record includes its title, URL slug, page type, summary, body, image information, search title and description, review date, and draft state. A unique slug prevents two records in this collection from claiming the same detail URL.
The body contains the article and its questions and answers. The page extracts the FAQ once and uses it for both the visible answers and FAQ structured data. Editors do not need to maintain separate copies of the same answer.
The website reads only eligible records
The production reader requires an explicit published state. A draft or empty publication flag does not qualify. A missing eligible record returns an unavailable page rather than invented sample content.
The site's credential for this collection can read the content table but has no write access. The public reading path is not the editorial editing interface. Authorized workspace users manage the records through PloyDB.
Publication changes more than the article
The title, summary, body, metadata, breadcrumb, and relevant schema come from the record and its template. The public Blog and Selected Work add eligible guide and case-study links. The Ploy sitemap and AI-readable index use published records, so an unpublished resource is not advertised as a working public destination.
That last rule matters. A page returning 404 is still a poor reader experience if public navigation promotes it. Check eligibility in the discovery lists as well as in the detail route.
Keep three environments and permissions distinct
The browser displays the page and lets a visitor follow links or send an enquiry. It does not need the content-table credential in its client code.
The website's server reads approved content with its scoped site credential. A deployed site needs that credential configured, and a new or replaced secret takes effect on the next publish. A successful preview does not by itself prove that the deployed reader is configured correctly.
The workspace is where authorized people and Ploy's Agent edit records and work through connected services. Membership, role permissions, service authorization, and write approval govern that work. Ploy's database documentation explains per-table key scope, while agency documentation explains organization-level member access.
Test publication and failure paths separately
| Check | Expected result |
|---|---|
| Public draft URL | Unavailable and excluded from search discovery. |
| Approved record | The correct page content and metadata appear at its intended URL. |
| Missing record | An unavailable page, not a sample article or another record. |
| Related lists | Only eligible records are linked from public guides, Blog, and Selected Work. |
| Old URL after a move | Redirects to an eligible replacement, not a draft destination. |
| Content editing | A saved, approved record change reaches the request-time website reader. |
| Credential scope | The website's content credential has only the access its reader needs. |
We tested the draft-to-public transition, the old-URL redirect, and the resulting discovery links on this site's public domain. We also inspected the content key's read-only table scope. That is different from testing a credential revocation or a live database outage; neither is claimed by this example.
For a client implementation, include credential configuration and service-availability failures in the acceptance plan. Define what a reader sees when content cannot be retrieved, who investigates the failure, and how the responsible editor knows that a retry or repair is needed. Do not equate an empty response with a successfully connected but empty table.
Define an external integration before building it
A CMS reader is already a connection between data and a page. Adding an external service introduces more decisions. Describe the exact operation, rather than asking to connect an entire CRM or automation platform without a defined job.
Write down the source and destination, the account owner, the permitted read or write action, the required input fields, and the intended output. State whether a person approves the action before it runs. Specify how missing data, expired access, provider refusal, and retry duplication are handled.
Ploy's integration documentation describes workspace connections and write-access approval. Ploybooks describe reusable Agent workflows, including work with connected tools. Those capabilities do not automatically create the equivalent feature for a public website visitor.
This own-site example does not show a CRM write, email automation, payment integration, or visitor account. A proposal for one of those jobs needs an implementation and test in the correct environment. Our human-controlled AI workflow guide provides the review and recovery questions to include.
Agree the handoff
Document the table fields, allowed publication states, page templates, account owner, and who can release content. Show the next editor how to create a draft, review the rendered result, release it, and confirm its public links.
For external connections, add the permitted operation, credential owner, renewal responsibility, and failure response. Identify which changes are content edits and which need another site deployment. Agree support separately rather than assuming a working first release includes indefinite maintenance.
Discuss your connected website with Kings Landing. Our Ploy systems service starts with a working content model and scoped actions, not an unverified list of integration promises.