Describe the constraints on guest users, and how you design around them.

The guest user is the most constrained identity on the platform, deliberately. It cannot own records. Its access is private by default and can only be widened through guest user sharing rules, which grant read access. It cannot be added to public groups or queues, and it should never be given broad object permissions.

The design consequence people run into: an anonymous visitor submits a form, and the business wants a confirmation page showing what they submitted. Because the guest user cannot own the record, there is no ownership path back to it. So either the confirmation is rendered from the data already in that request, or the visitor authenticates — and if they are going to authenticate, that is a registered external identity, not a guest.

The pattern I actively reject is a sharing rule that matches records on an email address the visitor typed. It looks like it satisfies the requirement and it lets anybody read anybody else's submission by typing their email. If unauthenticated write access to a business process is genuinely needed, I would put a controlled Apex service or a web-to-case style intake in front of it rather than widening guest sharing.