> ## Documentation Index > Fetch the complete documentation index at: https://docs.kayanos.com/llms.txt > Use this file to discover all available pages before exploring further. # Public portal > Publish a controlled public intake channel for eligible regular forms without exposing internal records, staff workspaces, or unrestricted submission access. ## A public portal is an intake boundary The KayanOS public portal lets a citizen discover and start approved public forms. It is not an external view of the internal KayanOS workspace, a public entity browser, or a shortcut around member roles. A public participant can work with their own permitted public session; they cannot use the portal to browse other citizens’ requests, internal queues, dashboards, documents, or staff records. Use the portal for a **Citizen Service Request** that starts an approved intake process. Keep internal review, inspection, decision, member-only fields, and administration behind the appropriate authenticated KayanOS permissions. ![KayanOS public portal configuration for Citizen Service Request intake.](https://kayanos.app/docs-images/en/build/public-portal.png) ## What makes a form eligible A form appears in the public portal only when all of these conditions are true: | Condition | Why it exists | What to test | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | | It is a **regular** form | Offline forms are controlled field-work packages, not public entry points. | An offline form must not appear in portal discovery. | | Public enablement is on | The form owner has deliberately exposed it to the portal. | Disable public enablement and confirm it disappears. | | A published version exists | A citizen must start a released, stable form structure. | A draft-only form must not be startable. | | The public end date has not passed | The route stops serving an expired form. | Test before/after the configured end date in the organization timezone/process. | | The public submission limit has not been reached | The portal enforces the form’s public-session cap. | Test the boundary using controlled data; the cap counts public sessions for that form. | | Account requirement is satisfied, when enabled | The form can require a registered public account rather than an anonymous-style public identity. | Try the form as an unregistered and a registered public participant. | If any condition fails, the portal treats the form as unavailable. Do not try to preserve access through an old copied link; fix the intended publication/availability condition or communicate the closure clearly. ## Design the citizen journey before publishing Write the complete journey from the citizen’s point of view: 1. The citizen finds **Citizen Service Request** under a clear topic/folder such as “Service requests.” 2. The portal shows a localized title, concise description, optional cover image, and icon that explain what the form is for and who may use it. 3. The citizen learns whether an account is required before beginning—not after entering a long set of values. 4. The citizen starts one public session, completes the fields, and receives only the permitted reference/status information. 5. Internal Registry, Field Inspection, and Decision teams continue the work in authenticated KayanOS surfaces. 6. If the form closes, reaches its cap, or requires an account, the portal gives a clear next channel rather than leaving the citizen to retry blindly. Avoid publicly collecting data that can be obtained later by the authorized service team. A public form is not a reason to expose internal status transitions, staff assignments, confidential checklists, or unrestricted document downloads. ## Configure portal information architecture ### Folders, order, and discoverability Publicly eligible forms can be organized into folders. The portal retrieves visible folders that are used by eligible forms and shows forms in their configured menu order, with creation time as a later ordering fallback. Use folders for plain-language services, not internal organizational jargon. Suggested public structure: | Folder | Forms | Citizen-facing intent | | -------------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------- | | Start a service request | Citizen Service Request | Begin a new service request or ask for an initial service review. | | Follow-up services | Approved follow-up form(s) | Add information only when the service process explicitly directs the citizen here. | | Information and assistance | Short assistance/contact forms, if released | Route questions without exposing case-management work. | Set one deliberate menu order and test search. Portal search matches visible form titles; it does not make a form eligible, search internal records, or bypass a folder/publication boundary. ### Identity, theme, and language The portal can use the organization’s display name, short description, logo, configured portal logo variants, and cover image. It also reads active organization languages and the organization default language, while the visitor can choose a supported portal language where available. Keep English and Arabic names, descriptions, labels, and help text equivalent in meaning. Review Arabic direction, line wrapping, dates, numerals, and the actual visible form content—not only the portal header. Use a neutral public-service visual identity. Do not use a screenshot, cover image, or form title that reveals live personal data, a private service reference, a token, or an internal team queue. ### Account-required versus public participant flow Every portal visitor is handled as a public participant, but a form can require a registered public account before it starts. The public sign-in/registration experience supports email and phone-based identity flows where the organization has configured and verified them. Do not hard-code a country-code assumption in instructions: confirm the organization’s phone/localization configuration and test it for the intended audience. | Choice | Appropriate for | Required safeguards | | ------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | No account required | Low-risk intake that does not need a returning identity beyond the public session boundary. | Minimize data, rate/volume-plan the service, and do not expose status/history beyond the allowed session. | | Account required | A service where the citizen must return to their own session/history or the process needs a registered public identity. | Test registration, sign-in, recovery, privacy wording, and the refusal path for an unregistered participant. | Requiring an account does not give that citizen member permissions. It only changes the public participant condition for the form. Where the account flow asks for a verification code, use the six-digit code from the configured email or phone channel within 10 minutes. A new code cannot be requested more than once per 60 seconds, and repeated requests are limited. Five wrong verification attempts lock that verification flow for 15 minutes; wait for the lock to end instead of trying alternate identities or asking staff to bypass it. Password recovery deliberately returns the same request acknowledgement whether or not an account exists. After a valid code, finish the reset within 15 minutes: the reset continuation is single-use. A successful password reset ends the account's existing sign-in sessions, so the participant must sign in again with the new password. Staff must not reveal whether an email address or phone number has an account, disclose a verification code, or reuse an internal member session to complete a public participant's recovery. ## Publish a controlled Citizen Service Request 1. Build and test the regular form in a non-production organization. Keep public-facing fields minimal; move internal review fields to authenticated steps. 2. Publish the intended form version. Confirm the form title, description, field labels, validation, Arabic/English text, and error messages are ready for citizens. 3. In public settings, enable the form and decide whether an account is required, whether an overall public submission limit is appropriate, and whether an end date is needed. 4. Place the form in the correct folder, set its menu order, icon, and cover image. Confirm search finds the title without relying on internal terms. 5. Configure/verify the organization’s portal name, logo/cover, active languages, and public participant account flows. 6. Test the portal in a clean browser session as a public participant. Start a request, save/submit it according to the form design, then verify the public view exposes only its own permitted session information. 7. Test an account-required denial, an expired form, a disabled form, and a cap-reached form using controlled data. Record the citizen-facing explanation and approved alternative channel for each. 8. Have an internal reviewer open the resulting session through normal member permissions and confirm no internal data became public. ## Public session boundary When a public participant starts an eligible form, KayanOS creates a session bound to that participant. Recent portal activity is limited to that participant’s own recent public sessions. A public participant cannot open a session merely by guessing or receiving someone else’s internal session ID. This boundary is important for follow-up design: * Use the returned/reference information that the form is designed to share. * Do not send internal session IDs, signed file URLs, or staff-only links in a public message. * Do not add a form expression or hidden field that looks up and renders data from another citizen’s request. * If a citizen needs a status update, design and test a released, permission-safe public response rather than exposing the internal record. ## Availability limits and closure behaviour | Setting or condition | Citizen experience | Administrator responsibility | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Public enablement off | The form is not discoverable/startable through the portal. | Use when the service is intentionally closed; remove or clarify external links. | | No published version | The form is unavailable. | Publish a reviewed version before enabling public service. | | End date passed | The form is no longer eligible for a new public session. | Publish the closing date/time and an alternative service channel before the deadline. | | Submission cap reached | A new public session is refused. | Set a realistic capacity, monitor usage, and decide whether to extend/reset through approved change control. | | Account required | An unregistered public participant is refused until they complete the configured account flow. | Test the whole identity flow and make the requirement visible before form completion. | | Form changed after launch | New public sessions use the currently published version; existing session interpretation must preserve its form-version context. | Test the change as a release, especially if fields, translations, or consent wording change. | Do not promise automatic reopening, backlog transfer, notification, or external delivery unless those outcomes are separately configured and verified in released KayanOS capabilities. ## Test matrix | Test | Expected result | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Discovery | Only eligible published regular forms appear in the intended folder/order. | | Search | A citizen can find a visible form by its localized public title; search reveals no internal forms/records. | | Arabic/English | Portal text, form labels, RTL layout, date/number presentation, and error messages are understandable in both active languages. | | No-account start | A form configured without account requirement follows its reviewed public participant flow. | | Account requirement | An unregistered participant is refused; a registered participant can start only after the configured flow succeeds. | | Account verification and recovery | A valid code works once within its time limit; resend throttling, wrong-code lockout, generic recovery acknowledgement, reset expiry, and sign-in again after reset behave as described. | | Date closure | The form works before the end date and is unavailable after it. | | Volume cap | A request at the configured cap is refused without creating an untracked duplicate session. | | Public-session isolation | One public participant cannot open another participant’s session or internal staff data. | | Internal handoff | Authorized staff can review the resulting session through normal scope/role rules. | ## Troubleshooting | Symptom | Likely cause | Check and resolve | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Form does not appear | It is not public-enabled, not regular, has no published version, has expired, or is in a different organization/folder setup. | Review each eligibility condition and the organization context; do not rely on an old direct link. | | “Account required” | The form requires a registered public participant. | Test the configured account flow; confirm the person is signed in to the correct public organization. | | Code is not accepted or a new code is not sent | The code expired, was already consumed, a resend was requested too soon, or five wrong attempts triggered a 15-minute lock. | Use only the newest code, wait at least 60 seconds before requesting another, and wait for the lock to end. Restart the authorized flow after expiry; staff must not bypass the controls. | | Recovery acknowledgement appears but no message arrives | Recovery never confirms whether the account exists; delivery may also be delayed or the request may be throttled. | Confirm the public organization, identifier, configured channel, and spam/message filtering without disclosing account existence. Wait for the resend interval, then use the approved support channel if delivery still fails. | | “Submission limit reached” | Public session count reached the configured cap. | Review capacity/closure policy and use the approved alternate channel; do not ask users to create duplicate requests. | | Citizen cannot see an expected session | The session is not owned by that public participant or the identity/session context changed. | Confirm the public account/session boundary; never work around it by sharing an internal link. | | Portal language/RTL looks wrong | Active language, default language, translation, or layout text is incomplete. | Verify active organization languages and test the portal/form in Arabic and English before publishing. | | Internal data appears in a public form | Field, expression, lookup, or document design crossed the boundary. | Immediately disable/restrict the public form if needed, preserve evidence, and review the public session/data exposure with an authorized owner. | ## Permissions and data-quality limits A public portal is intentionally narrower than an internal workspace. A public participant does not receive a member role or broad record access. Keep collection minimal, explain any account requirement and data purpose clearly, use plain-language validation, and test with approved non-production data. Staff must still use member permissions, scopes, and normal review processes to work with submitted sessions. ## Related guides * [Forms](/build/forms) * [Form submissions](/build/form-submissions) * [Form actions, logic, and signatures](/build/form-actions-logic-and-signatures) * [Permissions and availability](/reference/permissions-and-availability) * [Public API reference](/reference/public-api) * [Troubleshooting](/reference/troubleshooting)