Authentication first.
Team and owner workflows require an authenticated Turnli session. Public join, status, kiosk, display, and business-page experiences do not receive the full internal workspace.
Trust & security
Security claims should be specific, current, and verifiable.
Turnli separates public customer journeys from authenticated staff operations, keeps privileged actions behind server-side authorization, and uses external providers for sensitive functions such as payment processing and message delivery.
Current standard
No certification theater.
This page describes product and architecture boundaries Turnli can substantiate today. Do not infer SOC 2, ISO 27001, PCI certification, HIPAA eligibility, or another certification unless Turnli explicitly publishes that status here.
AccountsAuthenticated workspace access
AuthorizationServer-enforced roles and guarded operations
PaymentsProvider-hosted paid billing flows
TelemetryPrivacy-minimized browser diagnostics by default
Access boundaries
Public surfaces and staff operations are intentionally different systems.
Turnli’s browser UI is not treated as the final security boundary. Protected actions remain subject to authenticated account, workspace, role, plan, and backend authorization.
Permissions are enforced beyond navigation.
Turnli uses server-side authorization patterns for protected operations, including row-level controls and guarded RPC workflows where those systems apply.
Command Center stays separate.
Turnli platform-administration capabilities use their own protected authorization and audit paths rather than ordinary business-workspace access.
Hidden UI is not entitlement security.
Plan-specific navigation can simplify the product, but server-side entitlement checks remain authoritative for protected capabilities.
Customer data
Expose only the context each journey needs.
Turnli is designed so a customer-facing status experience does not need the same operational detail as the team running the business.
Guest views stay scoped.
Customer status experiences are built around the relevant journey rather than publishing the internal queue, team notes, floor capacity, or management controls.
Workspace context stays inside the workspace.
Queue, reservation, visit, Guestbook, communications, and management context are available according to the business workflow and authorized role.
Do not put secrets in ordinary fields.
Turnli is not designed for passwords, private keys, full payment-card numbers, government identifiers, or similarly sensitive secrets in notes or support content.
Providers & communications
External delivery does not erase Turnli’s guardrails.
Some functions depend on specialized providers. Turnli keeps provider status, consent, suppression, and handoff boundaries explicit instead of treating delivery as guaranteed.
Payment details stay with the payment provider.
Paid-plan checkout and billing-management flows use Stripe-hosted destinations. Turnli does not need full payment-card numbers in the product UI.
Transactional messaging requires communication controls.
SMS consent is separate from general terms. Opt-out and suppression state must remain authoritative, including STOP/HELP handling where the channel is enabled.
Sent is not the same as delivered.
Turnli surfaces delivery state and failures where supported rather than assuming an external provider completed the message.
Connected services keep their own boundaries.
A business-enabled integration can exchange only the information needed for that workflow; third-party services remain governed by their own terms and security practices.
Diagnostics & acquisition measurement
Measure the funnel without building an advertising profile.
Turnli’s default browser telemetry is a bounded session diagnostic buffer. The Shore 2 acquisition layer adds only sanitized source, campaign, plan, business-mode, and funnel-stage context.
No customer or message payloads for marketing measurement.
The acquisition bridge does not record email addresses, phone numbers, guest records, message contents, auth tokens, raw URLs, or raw referring URLs.
No remote analytics collector is enabled by default.
Browser diagnostics stay local unless Turnli explicitly configures a remote telemetry collector for an approved deployment.
Short-lived first-party context.
Sanitized campaign context is retained in session storage and can be carried through signup/onboarding so Turnli can understand which acquisition path produced a workspace without adding a third-party ad tracker.
Operational transparency
Availability and security state should be visible, not implied.
Turnli distinguishes live, refreshing, cached, degraded, and unavailable states where the underlying workflow supports that distinction. Historical timing and intelligence are guidance, not fabricated certainty.
Last confirmed state matters.
Where supported, temporary source failures retain the last confirmed snapshot and identify the degraded source instead of silently presenting stale information as current.
Frontend releases are versioned and manifest-verified.
Turnli release packages use synchronized release identifiers, service-worker cache boundaries, CSP hashes, and a self-excluding file-hash manifest for deployment verification.
Publish evidence before labels.
Turnli will not claim an audit, certification, penetration-test result, uptime commitment, or compliance status on this page unless the underlying evidence and scope can be stated accurately.
Need the policy detail?
Trust information should connect to the documents that govern it.
Use Privacy for data-handling detail, Terms for service obligations and limitations, and Support for product or workspace questions. Do not send passwords, private keys, or full payment-card numbers in a support request.