> For the complete documentation index, see [llms.txt](https://docs.atomyx.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.atomyx.io/atomyx-submit/implementation/implementation-patterns/common-patterns-and-lessons.md). # Common Patterns and Lessons These lessons are useful when planning a new deployment, especially if you are deciding how much to automate, how tightly to integrate with existing systems, and how to structure the customer journey. ### Common architecture patterns #### Two-stage preflight is the norm A lightweight check at upload gives immediate feedback. A deeper production preflight after submission allows more thorough correction and validation without harming the customer experience. #### Server-side processing is essential Customer edits must affect the real PDF, not only the preview. This keeps the approved output aligned with what actually proceeds to production. #### Proof generation is a key workflow step A proof page acts as the final agreement point between customer and provider. It reduces ambiguity and helps avoid disputes later in the process. #### Variables are better than profile sprawl A smaller set of parameterised processing profiles is usually easier to manage than maintaining many separate product-specific versions. ### Common business lessons #### Self-service reduces support load When customers can see issues and fix basic problems themselves, support volume drops. #### Automatic correction improves throughput Correcting common issues automatically keeps more work moving without human intervention. #### The portal should replace fragmented file communication When artwork handling is split across emails, shared links, and manual status updates, the process becomes harder to track and scale. #### Phased delivery is usually the right approach Start with upload, preview, and core validation. Add advanced editing, proofing, and deeper automation once the foundation is stable. ### Common technical lessons #### Plan for real usage volume A seemingly simple submission flow may generate many API actions once upload checks, preflight, preview generation, and proof creation are taken into account. #### Design for resubmission Customers will upload revised files. The workflow should handle versioning and repeated submission cleanly. #### Think about mobile early If mobile or tablet use is likely, it is much easier to plan for that from the start than retrofit it later. #### Test with real-world files Reference samples are helpful, but actual customer artwork is what reveals the edge cases that matter in production. ### Practical takeaway The strongest Atomyx Submit implementations are usually the ones that: * keep the customer journey simple * centralise file communication * separate fast feedback from deeper production checks * automate the common path * escalate only the true exceptions --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.atomyx.io/atomyx-submit/implementation/implementation-patterns/common-patterns-and-lessons.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.