AI app guides
Why an Emergent app can work in preview and fail after publishing
Check environment settings, sample data and external connections before treating a preview result as live evidence.
Zocri · 2 min read · Sources checked
Begin with one failing journey
Emergent documents preview and production as separate environments with separate sets of environment variables. A successful preview therefore does not settle every live setup question. Start by writing the precise failure: the form loads on the published address, but a submitted request never reaches the owner. Avoid describing the entire app as broken if one step is failing.
Repeat the same safe example in both environments. Note the address, account, action and visible result. Confirm that the published app contains the version you intended to release. A missing change and a failing connection can look similar from the customer's side but need different fixes.
Compare configuration by purpose
Make a list of required services: sign-in, record storage, file storage and message delivery. Check whether each has its intended production configuration. Inspect names and status without copying secret values into a bug report or chat transcript. Identify the owner responsible for each connected account.
A preview might use test recipients or sample settings that are unsuitable for the live journey. Check the configured sender, return address and permitted application address where relevant. Use the provider's own evidence to establish whether a request arrived, failed or never left the app.
Separate missing data from broken behavior
Check whether the live app contains the services, categories and owner account that the journey needs. A blank list may be the correct result for a newly initialized environment. Write an explicit production setup step for required reference data rather than relying on accidental preview content.
Keep sample customer records out of this setup unless they are clearly marked and appropriate. Confirm that the owner can create and edit a real service through the intended interface. An app that depends on manually inserted preview records needs that dependency resolved before ordinary operation.
Retest after the narrow correction
Change the identified setting or setup gap, publish the appropriate version and repeat the original case. Verify both the customer result and the owner's record. If an external service is involved, check its side too; a success message in the app may occur before delivery completes.
Save the final explanation in an environment checklist with no secret values. Include the symptom, the actual cause and the verification performed. That record makes the next release easier to inspect and helps distinguish a recurring setup mistake from a new code or service failure.