Support

FAQ

All Getting started Import Editing Publishing Domains Roles Billing Support Security Websites

What is Loreto Sites for?

Loreto Sites is the admin side for creating, editing, publishing, hosting, and managing parish and school websites.

In-depth answer+

Loreto Sites uses a draft-first workflow: create or import a site shell, review generated content, make edits in draft, preview the public experience, then publish only after approval. The dashboard is intended to be the operational source of truth for the next required action.

Technical checks

Confirm whether the site should begin from an import or from scratch. Use import when a public website already has useful structure, Mass times, staff pages, bulletins, or event content.
Check that the organization name, current website URL, primary contact, and site type are correct before sending a request. Incorrect intake data can create duplicate organizations or hard-to-match drafts.
After sign-in, verify that the dashboard shows the expected site and that the user has access to edit content, publish, or manage billing depending on the task.
If a draft appears missing, include the URL submitted, the approximate import time, and the Google account used to sign in so support can trace the import claim and organization membership.

Escalation details to include

Send support the site URL, organization name, user email, and the exact screen where the workflow stopped.
Attach a screenshot if the dashboard shows no site, the wrong site, or a disabled next-step button.
Do not restart the import repeatedly for the same website unless support asks you to. Duplicate imports can make ownership and review history harder to follow.

Reference notes

Dashboard: shows the next recommended setup, review, publish, billing, or domain action.
Import flow: creates a draft from public website content and stores the review state before publish.
Scratch flow: creates a structured draft from manual answers when no usable source website exists.
Support request: use when the app state and expected next action do not match.

What should I do first after signing in?

Start with one guided setup path: import an existing website or create a new draft. The dashboard keeps the next step visible so you only need to handle one decision at a time.

In-depth answer+

Technical checks

Confirm whether the site should begin from an import or from scratch. Use import when a public website already has useful structure, Mass times, staff pages, bulletins, or event content.
Check that the organization name, current website URL, primary contact, and site type are correct before sending a request. Incorrect intake data can create duplicate organizations or hard-to-match drafts.
After sign-in, verify that the dashboard shows the expected site and that the user has access to edit content, publish, or manage billing depending on the task.
If a draft appears missing, include the URL submitted, the approximate import time, and the Google account used to sign in so support can trace the import claim and organization membership.

Escalation details to include

Send support the site URL, organization name, user email, and the exact screen where the workflow stopped.
Attach a screenshot if the dashboard shows no site, the wrong site, or a disabled next-step button.
Do not restart the import repeatedly for the same website unless support asks you to. Duplicate imports can make ownership and review history harder to follow.

Reference notes

Dashboard: shows the next recommended setup, review, publish, billing, or domain action.
Import flow: creates a draft from public website content and stores the review state before publish.
Scratch flow: creates a structured draft from manual answers when no usable source website exists.
Support request: use when the app state and expected next action do not match.

Can one parish manage more than one site?

Yes. A parish can manage parish, school, campaign, ministry, and location-specific sites from the same dashboard when the plan and permissions allow it.

In-depth answer+

Technical checks

Confirm whether the site should begin from an import or from scratch. Use import when a public website already has useful structure, Mass times, staff pages, bulletins, or event content.
Check that the organization name, current website URL, primary contact, and site type are correct before sending a request. Incorrect intake data can create duplicate organizations or hard-to-match drafts.
After sign-in, verify that the dashboard shows the expected site and that the user has access to edit content, publish, or manage billing depending on the task.
If a draft appears missing, include the URL submitted, the approximate import time, and the Google account used to sign in so support can trace the import claim and organization membership.

Escalation details to include

Send support the site URL, organization name, user email, and the exact screen where the workflow stopped.
Attach a screenshot if the dashboard shows no site, the wrong site, or a disabled next-step button.
Do not restart the import repeatedly for the same website unless support asks you to. Duplicate imports can make ownership and review history harder to follow.

Reference notes

Dashboard: shows the next recommended setup, review, publish, billing, or domain action.
Import flow: creates a draft from public website content and stores the review state before publish.
Scratch flow: creates a structured draft from manual answers when no usable source website exists.
Support request: use when the app state and expected next action do not match.

What does the website import do?

The import reads your current public website, prepares a draft structure, gathers likely pages, and suggests content that staff can review before anything is published.

In-depth answer+

The import process reads public pages, classifies relevant content, prepares draft pages, imports usable images when available, and records suggestions for staff review. Imported content is not public until an authorized user approves and publishes the draft.

Technical checks

Compare the source website and draft page by page. Note missing pages, incorrect titles, broken imported images, wrong Mass times, or content placed in the wrong section.
Check whether the source page is publicly reachable without a login, cookie banner block, bot block, or PDF-only layout. The importer cannot reliably read private pages or heavily scripted content.
For missing images, verify that the source image is not behind a hotlink block, lazy-loading script, or very large file. Attach the original source URL when possible.
For bulletins or PDFs, include the PDF URL and the exact text that should be extracted if the imported result is incomplete.

Escalation details to include

Send the submitted website URL, draft site ID if visible, source page URL, draft page name, expected content, actual content, and screenshots.
For classification problems, state whether the organization is a parish, school, ministry, or mixed parish-school structure.
For failed imports, include the time the import started and any visible error message so support can match the job to logs.

Reference notes

Import statuses: queued, crawling, extracting, preparing, completed, or failed.
Draft storage: imported pages and basics are saved as draft content and remain separate from published content.
Review rule: imported suggestions should be accepted, edited, or ignored before publishing.
Limitations: blocked pages, private portals, unstable scripts, malformed HTML, and oversized media can reduce import quality.

Will the import publish changes automatically?

No. Imported content stays in draft or review until an authorized user approves and publishes it.

In-depth answer+

Technical checks

Compare the source website and draft page by page. Note missing pages, incorrect titles, broken imported images, wrong Mass times, or content placed in the wrong section.
Check whether the source page is publicly reachable without a login, cookie banner block, bot block, or PDF-only layout. The importer cannot reliably read private pages or heavily scripted content.
For missing images, verify that the source image is not behind a hotlink block, lazy-loading script, or very large file. Attach the original source URL when possible.
For bulletins or PDFs, include the PDF URL and the exact text that should be extracted if the imported result is incomplete.

Escalation details to include

Send the submitted website URL, draft site ID if visible, source page URL, draft page name, expected content, actual content, and screenshots.
For classification problems, state whether the organization is a parish, school, ministry, or mixed parish-school structure.
For failed imports, include the time the import started and any visible error message so support can match the job to logs.

Reference notes

Import statuses: queued, crawling, extracting, preparing, completed, or failed.
Draft storage: imported pages and basics are saved as draft content and remain separate from published content.
Review rule: imported suggestions should be accepted, edited, or ignored before publishing.
Limitations: blocked pages, private portals, unstable scripts, malformed HTML, and oversized media can reduce import quality.

What if the import misses a page, image, bulletin, or event?

Use the review screens to add or correct missing content. If the source site blocks crawling or has unusual structure, send a support request with the current URL and what is missing.

In-depth answer+

Technical checks

Compare the source website and draft page by page. Note missing pages, incorrect titles, broken imported images, wrong Mass times, or content placed in the wrong section.
Check whether the source page is publicly reachable without a login, cookie banner block, bot block, or PDF-only layout. The importer cannot reliably read private pages or heavily scripted content.
For missing images, verify that the source image is not behind a hotlink block, lazy-loading script, or very large file. Attach the original source URL when possible.
For bulletins or PDFs, include the PDF URL and the exact text that should be extracted if the imported result is incomplete.

Escalation details to include

Send the submitted website URL, draft site ID if visible, source page URL, draft page name, expected content, actual content, and screenshots.
For classification problems, state whether the organization is a parish, school, ministry, or mixed parish-school structure.
For failed imports, include the time the import started and any visible error message so support can match the job to logs.

Reference notes

Import statuses: queued, crawling, extracting, preparing, completed, or failed.
Draft storage: imported pages and basics are saved as draft content and remain separate from published content.
Review rule: imported suggestions should be accepted, edited, or ignored before publishing.
Limitations: blocked pages, private portals, unstable scripts, malformed HTML, and oversized media can reduce import quality.

How do I edit the website?

Open the site from your dashboard, choose the section you want to update, make the draft change, preview it, then publish when it is ready.

In-depth answer+

Editing happens in draft so changes can be reviewed before they affect the live site. A clean editing process separates content changes, media changes, navigation changes, and publish approval.

Technical checks

Confirm you are editing the intended page and draft, not reviewing an older published version.
Preview the affected page after edits and check mobile width, desktop width, image cropping, links, and any repeated content blocks.
For layout issues, identify the page, section, block title, browser size, and whether the issue occurs in preview, editor, or published site.
For text or data updates like Mass times, staff, events, or announcements, include the exact replacement copy and whether the change is temporary or permanent.

Escalation details to include

Send the page URL or editor route, the block or field name, what you changed, what you expected, and what happened after saving.
Attach before and after screenshots for visual regressions, especially mobile layout, overlapping text, or cropped images.
If save fails, copy the visible error text and note whether the same change works on another page.

Reference notes

Draft: editable content that is not yet public.
Preview: the review surface for checking draft changes before publish.
Version history: used to compare, rename, or restore meaningful saved versions.
Audit context: sensitive changes such as giving links should be treated as publish-reviewed changes.

Can I restore an older version?

Yes. Version history is designed for safe publishing, so important changes can be reviewed and restored when available.

In-depth answer+

Editing happens in draft so changes can be reviewed before they affect the live site. A clean editing process separates content changes, media changes, navigation changes, and publish approval.

Technical checks

Confirm you are editing the intended page and draft, not reviewing an older published version.
Preview the affected page after edits and check mobile width, desktop width, image cropping, links, and any repeated content blocks.
For layout issues, identify the page, section, block title, browser size, and whether the issue occurs in preview, editor, or published site.
For text or data updates like Mass times, staff, events, or announcements, include the exact replacement copy and whether the change is temporary or permanent.

Escalation details to include

Send the page URL or editor route, the block or field name, what you changed, what you expected, and what happened after saving.
Attach before and after screenshots for visual regressions, especially mobile layout, overlapping text, or cropped images.
If save fails, copy the visible error text and note whether the same change works on another page.

Reference notes

Draft: editable content that is not yet public.
Preview: the review surface for checking draft changes before publish.
Version history: used to compare, rename, or restore meaningful saved versions.
Audit context: sensitive changes such as giving links should be treated as publish-reviewed changes.

Can I change Mass times, confession, adoration, staff, events, and announcements?

Yes. Those are first-class parish content areas so staff can update them without redesigning pages.

In-depth answer+

Editing happens in draft so changes can be reviewed before they affect the live site. A clean editing process separates content changes, media changes, navigation changes, and publish approval.

Technical checks

Confirm you are editing the intended page and draft, not reviewing an older published version.
Preview the affected page after edits and check mobile width, desktop width, image cropping, links, and any repeated content blocks.
For layout issues, identify the page, section, block title, browser size, and whether the issue occurs in preview, editor, or published site.
For text or data updates like Mass times, staff, events, or announcements, include the exact replacement copy and whether the change is temporary or permanent.

Escalation details to include

Send the page URL or editor route, the block or field name, what you changed, what you expected, and what happened after saving.
Attach before and after screenshots for visual regressions, especially mobile layout, overlapping text, or cropped images.
If save fails, copy the visible error text and note whether the same change works on another page.

Reference notes

Draft: editable content that is not yet public.
Preview: the review surface for checking draft changes before publish.
Version history: used to compare, rename, or restore meaningful saved versions.
Audit context: sensitive changes such as giving links should be treated as publish-reviewed changes.

What is the difference between draft, preview, and published?

Draft is work in progress, preview is what you review before launch, and published is what visitors see on the live website.

In-depth answer+

Publishing converts reviewed draft content into the public version and may trigger deployment, cache, sitemap, and domain checks. A publish should be treated as a release step, not a normal save.

Technical checks

Confirm the preview is correct before publishing. Check homepage, key navigation, Mass times, giving links, contact pages, and any page changed in the current draft.
Verify the user has publish permission. Editors may be able to draft content without being allowed to make it live.
Check domain readiness before launch: DNS records, SSL status, canonical host, redirect behavior, and whether an old host should remain active during transition.
After publish, open the live URL in a fresh browser session if possible and check that the expected version appears.

Escalation details to include

Send the site ID, publish time, user email, visible error, and whether the issue happened before, during, or after publish.
For stale live content, include the preview URL, live URL, and which section differs.
For deployment errors, include whether the domain was recently changed or DNS records were edited.

Reference notes

Publish permission: required for making a draft public.
Deployment: the build or hosting update that serves the published files.
Rollback: use version history when a known previous state needs to be restored.
Cache behavior: DNS, CDN, or browser cache can delay visible changes after successful publish.

What happens if publishing fails?

The existing live site should stay intact, the failure is logged, and support can review the diagnostic details. Send a support request if the dashboard does not already explain the next step.

In-depth answer+

Publishing converts reviewed draft content into the public version and may trigger deployment, cache, sitemap, and domain checks. A publish should be treated as a release step, not a normal save.

Technical checks

Confirm the preview is correct before publishing. Check homepage, key navigation, Mass times, giving links, contact pages, and any page changed in the current draft.
Verify the user has publish permission. Editors may be able to draft content without being allowed to make it live.
Check domain readiness before launch: DNS records, SSL status, canonical host, redirect behavior, and whether an old host should remain active during transition.
After publish, open the live URL in a fresh browser session if possible and check that the expected version appears.

Escalation details to include

Send the site ID, publish time, user email, visible error, and whether the issue happened before, during, or after publish.
For stale live content, include the preview URL, live URL, and which section differs.
For deployment errors, include whether the domain was recently changed or DNS records were edited.

Reference notes

Publish permission: required for making a draft public.
Deployment: the build or hosting update that serves the published files.
Rollback: use version history when a known previous state needs to be restored.
Cache behavior: DNS, CDN, or browser cache can delay visible changes after successful publish.

What DNS records should our IT person add?

For a Vercel-hosted launch, use A @ 76.76.21.21 and CNAME www cname.vercel-dns.com unless the domain screen gives different records for your setup.

In-depth answer+

Domain setup connects a public hostname to the published site. The risky part is DNS: website records can be changed without disrupting email, but MX, SPF, DKIM, DMARC, donation, and other provider records should not be removed.

Technical checks

Identify the DNS provider, not just the registrar. The registrar sells the domain; DNS may be hosted elsewhere.
Before editing records, screenshot existing DNS settings and preserve email records such as MX, SPF, DKIM, and DMARC.
Check whether the requested hostname is root domain, www, subdomain, or preview domain. Each can require different records.
Allow for DNS propagation. Some providers update quickly, while cached records can take longer to resolve globally.

Escalation details to include

Send the domain, DNS provider, screenshot of current records, desired live URL, and any verification error.
If email is affected, stop changing records and include the mail provider name, changed records, and timing.
For SSL or verification failures, include both root and www behavior if they differ.

Reference notes

A record: points a root domain to an IP address when required by the hosting provider.
CNAME: points a hostname such as www to another hostname.
TXT: used for verification, SPF, DKIM, and other provider ownership records.
MX: routes email. Do not delete MX records when launching a website.

Should we remove old DNS records?

No. Keep MX, TXT, email, donation, school, and verification records unless your IT provider confirms they are obsolete.

In-depth answer+

Technical checks

Identify the DNS provider, not just the registrar. The registrar sells the domain; DNS may be hosted elsewhere.
Before editing records, screenshot existing DNS settings and preserve email records such as MX, SPF, DKIM, and DMARC.
Check whether the requested hostname is root domain, www, subdomain, or preview domain. Each can require different records.
Allow for DNS propagation. Some providers update quickly, while cached records can take longer to resolve globally.

Escalation details to include

Send the domain, DNS provider, screenshot of current records, desired live URL, and any verification error.
If email is affected, stop changing records and include the mail provider name, changed records, and timing.
For SSL or verification failures, include both root and www behavior if they differ.

Reference notes

A record: points a root domain to an IP address when required by the hosting provider.
CNAME: points a hostname such as www to another hostname.
TXT: used for verification, SPF, DKIM, and other provider ownership records.
MX: routes email. Do not delete MX records when launching a website.

Can someone else connect the domain?

Yes. Use the domain page to send clean instructions to your office manager, IT provider, registrar contact, or whoever controls DNS.

In-depth answer+

Technical checks

Identify the DNS provider, not just the registrar. The registrar sells the domain; DNS may be hosted elsewhere.
Before editing records, screenshot existing DNS settings and preserve email records such as MX, SPF, DKIM, and DMARC.
Check whether the requested hostname is root domain, www, subdomain, or preview domain. Each can require different records.
Allow for DNS propagation. Some providers update quickly, while cached records can take longer to resolve globally.

Escalation details to include

Send the domain, DNS provider, screenshot of current records, desired live URL, and any verification error.
If email is affected, stop changing records and include the mail provider name, changed records, and timing.
For SSL or verification failures, include both root and www behavior if they differ.

Reference notes

A record: points a root domain to an IP address when required by the hosting provider.
CNAME: points a hostname such as www to another hostname.
TXT: used for verification, SPF, DKIM, and other provider ownership records.
MX: routes email. Do not delete MX records when launching a website.

What if we do not know who manages our domain?

That is common. Check old website invoices, email-provider records, the parish office manager, or the IT provider. The domain page can still prepare instructions for whoever has access.

In-depth answer+

Technical checks

Identify the DNS provider, not just the registrar. The registrar sells the domain; DNS may be hosted elsewhere.
Before editing records, screenshot existing DNS settings and preserve email records such as MX, SPF, DKIM, and DMARC.
Check whether the requested hostname is root domain, www, subdomain, or preview domain. Each can require different records.
Allow for DNS propagation. Some providers update quickly, while cached records can take longer to resolve globally.

Escalation details to include

Send the domain, DNS provider, screenshot of current records, desired live URL, and any verification error.
If email is affected, stop changing records and include the mail provider name, changed records, and timing.
For SSL or verification failures, include both root and www behavior if they differ.

Reference notes

A record: points a root domain to an IP address when required by the hosting provider.
CNAME: points a hostname such as www to another hostname.
TXT: used for verification, SPF, DKIM, and other provider ownership records.
MX: routes email. Do not delete MX records when launching a website.

Why does SSL or verification still say pending?

DNS can take time to propagate, and old records can conflict. Confirm the exact records, avoid changing mail records, then use Check Connection again from the domain screen.

In-depth answer+

Technical checks

Identify the DNS provider, not just the registrar. The registrar sells the domain; DNS may be hosted elsewhere.
Before editing records, screenshot existing DNS settings and preserve email records such as MX, SPF, DKIM, and DMARC.
Check whether the requested hostname is root domain, www, subdomain, or preview domain. Each can require different records.
Allow for DNS propagation. Some providers update quickly, while cached records can take longer to resolve globally.

Escalation details to include

Send the domain, DNS provider, screenshot of current records, desired live URL, and any verification error.
If email is affected, stop changing records and include the mail provider name, changed records, and timing.
For SSL or verification failures, include both root and www behavior if they differ.

Reference notes

A record: points a root domain to an IP address when required by the hosting provider.
CNAME: points a hostname such as www to another hostname.
TXT: used for verification, SPF, DKIM, and other provider ownership records.
MX: routes email. Do not delete MX records when launching a website.

Can parish staff have different permissions?

Yes. Owners, admins, editors, and viewers can be separated so sensitive actions like billing, domains, deletion, and publishing stay controlled.

In-depth answer+

Roles and permissions control who can edit content, publish, manage billing, configure domains, upload assets, and invite other users. Access should follow least privilege: give each user only the permissions needed for their work.

Technical checks

Confirm the user is signed in with the expected email address. Google account aliases and parish emails can easily be confused.
Check whether the user is active, invited, suspended, or attached to the wrong organization.
Confirm the user has access to the specific site, not only the parent organization.
Match the blocked action to the required permission: content edit, publish, billing, domain setup, analytics, or people management.

Escalation details to include

Send the user email, organization, site, expected role, blocked page, and blocked action.
If an invitation failed, include the invited email, sender email, approximate send time, and whether the link expired.
If ownership is wrong, include who should be owner and who currently appears to control the account.

Reference notes

Owner or admin: can usually manage organization-level settings and critical access.
Editor: can change draft content but may not publish.
Publisher: can approve and publish live changes.
Viewer or restricted roles: can inspect content or analytics without changing production state.

Who should be an owner?

Use owners sparingly: typically the pastor, business manager, communications lead, or trusted administrator responsible for billing and critical settings.

In-depth answer+

Technical checks

Confirm the user is signed in with the expected email address. Google account aliases and parish emails can easily be confused.
Check whether the user is active, invited, suspended, or attached to the wrong organization.
Confirm the user has access to the specific site, not only the parent organization.
Match the blocked action to the required permission: content edit, publish, billing, domain setup, analytics, or people management.

Escalation details to include

Send the user email, organization, site, expected role, blocked page, and blocked action.
If an invitation failed, include the invited email, sender email, approximate send time, and whether the link expired.
If ownership is wrong, include who should be owner and who currently appears to control the account.

Reference notes

Owner or admin: can usually manage organization-level settings and critical access.
Editor: can change draft content but may not publish.
Publisher: can approve and publish live changes.
Viewer or restricted roles: can inspect content or analytics without changing production state.

Can we cancel any time?

Plans are intended to be manageable from billing settings. If a subscription, invoice, or cancellation option is unclear, send a billing support request before making changes.

In-depth answer+

Billing determines the active plan, subscription status, invoices, and payment portal access. Billing state should be checked before publishing constraints, cancellation requests, or plan changes are treated as content issues.

Technical checks

Confirm the organization and site attached to the subscription. Multi-site organizations may not map one invoice to one website.
Check whether the subscription is trialing, active, past due, canceled, or not yet configured.
For payment updates, use the billing portal rather than sending card details through support.
For invoice questions, collect invoice date, amount, organization name, and billing contact email.

Escalation details to include

Send the organization name, billing email, plan, invoice or subscription reference if visible, and the action you expected to take.
For cancellation, state whether you want to stop renewal, remove a site, or take a site offline. Those are different operational requests.
Never paste full card numbers, bank details, or private payment credentials into support.

Reference notes

Billing portal: secure place for payment method and invoice management.
Trialing: active evaluation period before normal billing.
Past due: payment needs attention and may restrict future publish or account actions.
Plan: controls available features, limits, and support level.

Can we upgrade or downgrade later?

Yes. Billing is structured so organizations can move between Starter, Parish, and Parish + School when their needs change.

In-depth answer+

Technical checks

Confirm the organization and site attached to the subscription. Multi-site organizations may not map one invoice to one website.
Check whether the subscription is trialing, active, past due, canceled, or not yet configured.
For payment updates, use the billing portal rather than sending card details through support.
For invoice questions, collect invoice date, amount, organization name, and billing contact email.

Escalation details to include

Send the organization name, billing email, plan, invoice or subscription reference if visible, and the action you expected to take.
For cancellation, state whether you want to stop renewal, remove a site, or take a site offline. Those are different operational requests.
Never paste full card numbers, bank details, or private payment credentials into support.

Reference notes

Billing portal: secure place for payment method and invoice management.
Trialing: active evaluation period before normal billing.
Past due: payment needs attention and may restrict future publish or account actions.
Plan: controls available features, limits, and support level.

What happens to a live site if billing needs review?

Support should review account status before any disruptive action. Send a billing request with the organization name, site, and the invoice or subscription question.

In-depth answer+

Technical checks

Confirm the organization and site attached to the subscription. Multi-site organizations may not map one invoice to one website.
Check whether the subscription is trialing, active, past due, canceled, or not yet configured.
For payment updates, use the billing portal rather than sending card details through support.
For invoice questions, collect invoice date, amount, organization name, and billing contact email.

Escalation details to include

Send the organization name, billing email, plan, invoice or subscription reference if visible, and the action you expected to take.
For cancellation, state whether you want to stop renewal, remove a site, or take a site offline. Those are different operational requests.
Never paste full card numbers, bank details, or private payment credentials into support.

Reference notes

Billing portal: secure place for payment method and invoice management.
Trialing: active evaluation period before normal billing.
Past due: payment needs attention and may restrict future publish or account actions.
Plan: controls available features, limits, and support level.

How fast will you respond?

We try to get back as soon as possible. Include the site, domain, what you expected, what happened, and any screenshots or exact error text.

In-depth answer+

A strong support request should let someone reproduce the issue without asking for the same context again. The most useful requests include environment, site, page, action, expected result, actual result, and screenshots.

Technical checks

Include the exact page URL and whether the issue occurs in dashboard, editor, preview, published site, billing, domain setup, or onboarding.
Describe the action in sequence: clicked button, selected value, uploaded file, saved page, published draft, or changed DNS record.
Attach up to two screenshots when the problem is visual or provider settings matter. The form accepts PNG, JPG, and WebP images up to 5 MB each.
If the issue is intermittent, include the time, browser, device, and whether refreshing or signing out changes the result.

Escalation details to include

Use the support form for normal issues so the request is logged with context.
Use text for urgent follow-up, especially launch blockers or domain cutover problems.
Avoid sending secrets. Redact tokens, passwords, private keys, and full payment information from screenshots.

Reference notes

Support issue: logged request with topic, details, and optional attachment metadata.
Email notification: support receives the request and validated screenshots as attachments.
Image protection: attachments are count-limited, type-limited, size-limited, and checked by file signature.
Triage priority: launch blockers, domain outages, access loss, and billing blockers should include clear urgency.

When should I send a support request instead of calling?

Use the support request for most issues because it records the details and routes the issue cleanly. Texting is best for urgent human follow-up.

In-depth answer+

Technical checks

Include the exact page URL and whether the issue occurs in dashboard, editor, preview, published site, billing, domain setup, or onboarding.
Describe the action in sequence: clicked button, selected value, uploaded file, saved page, published draft, or changed DNS record.
Attach up to two screenshots when the problem is visual or provider settings matter. The form accepts PNG, JPG, and WebP images up to 5 MB each.
If the issue is intermittent, include the time, browser, device, and whether refreshing or signing out changes the result.

Escalation details to include

Use the support form for normal issues so the request is logged with context.
Use text for urgent follow-up, especially launch blockers or domain cutover problems.
Avoid sending secrets. Redact tokens, passwords, private keys, and full payment information from screenshots.

Reference notes

Support issue: logged request with topic, details, and optional attachment metadata.
Email notification: support receives the request and validated screenshots as attachments.
Image protection: attachments are count-limited, type-limited, size-limited, and checked by file signature.
Triage priority: launch blockers, domain outages, access loss, and billing blockers should include clear urgency.

Where are sensitive API keys handled?

Sensitive server actions should run through backend routes or cloud functions with secrets stored outside browser code. Do not paste private keys into public website content.

In-depth answer+

Security-sensitive work includes authentication, authorization, secrets, uploads, publishing permission, billing access, and domain ownership. The safest support requests describe the symptom without exposing private credentials.

Technical checks

Do not paste passwords, API keys, private keys, service account JSON, recovery codes, or full payment details into public fields.
For access concerns, note the user email, role, organization, site, action attempted, and whether the user should have that permission.
For suspicious activity, include timestamps, affected pages, user accounts, and what changed.
For upload or attachment issues, include file type and size, but do not attach files containing private records unless support specifically requests a secure path.

Escalation details to include

For suspected account compromise, revoke access first if you can, then send support the affected email and timing.
For accidentally shared secrets, rotate the secret in the original provider and tell support what type of secret was exposed.
For publishing or billing permission problems, include the expected approver and current blocked user.

Reference notes

Authentication: proves who the user is.
Authorization: controls what the user can do after sign-in.
App Check and rate limiting: reduce abusive automated requests where enabled.
Audit trail: security-relevant actions should retain enough context for review.

Are critical errors monitored?

Production errors are logged and important failures can notify the operator. If you see a repeated issue, send the exact time, page, and action so support can match it to logs.

In-depth answer+

Technical checks

Do not paste passwords, API keys, private keys, service account JSON, recovery codes, or full payment details into public fields.
For access concerns, note the user email, role, organization, site, action attempted, and whether the user should have that permission.
For suspicious activity, include timestamps, affected pages, user accounts, and what changed.
For upload or attachment issues, include file type and size, but do not attach files containing private records unless support specifically requests a secure path.

Escalation details to include

For suspected account compromise, revoke access first if you can, then send support the affected email and timing.
For accidentally shared secrets, rotate the secret in the original provider and tell support what type of secret was exposed.
For publishing or billing permission problems, include the expected approver and current blocked user.

Reference notes

Authentication: proves who the user is.
Authorization: controls what the user can do after sign-in.
App Check and rate limiting: reduce abusive automated requests where enabled.
Audit trail: security-relevant actions should retain enough context for review.

Can we connect giving, calendars, email signups, or forms?

Yes. Use approved links and safe embeds for providers such as giving platforms, calendars, email signup tools, and parish forms.

In-depth answer+

Website structure can represent a parish, school, ministry, location, campaign, or mixed parish-school organization. The right structure depends on ownership, navigation, branding, publishing responsibility, and domain strategy.

Technical checks

Decide whether the content should be a full standalone site, a section inside another site, an external link, or a location-specific page.
List required top-level navigation, required public actions, important recurring content, and any pages that must keep their old URLs.
For integrations, identify whether the provider supports a normal link, embed, script, iframe, calendar feed, donation URL, or form endpoint.
Check mobile readability, accessibility, contact paths, giving links, and whether time-sensitive content has an owner.

Escalation details to include

Send the desired public URL, organization relationship, must-have sections, current provider links, and examples of pages you like or dislike.
For school or ministry content inside a parish site, state who owns publishing approval and whether branding should match or differ.
For redirects, provide old URL and new destination pairs.

Reference notes

Standalone site: independent navigation, domain, publish flow, and analytics.
Section: content lives inside a parent site with shared navigation.
External link: sends visitors to an existing provider or separate site.
Embed: displays provider content in a page when the provider allows safe embedding.

Can a school live as its own website or as a section?

Yes. A school can be managed as a full site, a section inside the parish site, or an external link depending on the organization setup.

In-depth answer+

Technical checks

Decide whether the content should be a full standalone site, a section inside another site, an external link, or a location-specific page.
List required top-level navigation, required public actions, important recurring content, and any pages that must keep their old URLs.
For integrations, identify whether the provider supports a normal link, embed, script, iframe, calendar feed, donation URL, or form endpoint.
Check mobile readability, accessibility, contact paths, giving links, and whether time-sensitive content has an owner.

Escalation details to include

Send the desired public URL, organization relationship, must-have sections, current provider links, and examples of pages you like or dislike.
For school or ministry content inside a parish site, state who owns publishing approval and whether branding should match or differ.
For redirects, provide old URL and new destination pairs.

Reference notes

Standalone site: independent navigation, domain, publish flow, and analytics.
Section: content lives inside a parent site with shared navigation.
External link: sends visitors to an existing provider or separate site.
Embed: displays provider content in a page when the provider allows safe embedding.

Contact us

Include the domain, current site or dashboard URL, what changed, what you expected, and a screenshot when the issue is visual.

Need urgent help?

We will get back to you as soon as possible.

Text support