Quick question: I saw a community post from ~3 years ago suggesting the QuickSight UI can silently swallow errors that the API throws in STRICT validationMode (e.g., just ignoring a problematic calculated field with no broken visuals or error messages).
When I tested this myself, I got no errors from either the UI or API.
I wanted to confirm: is it possible for the UI (which uses LENIENT validation) to silently drop an entity without any indication of failure, or does it always either fully succeed or visibly fail per visual? So for example if you tried using an invalid calculated field in a visual using the UI, is it possible that it would just ignore the field but display the rest of the visual fine? Then you won’t know something was wrong till you use STRICT mode
The ValidationStrategy parameter controls how strictly QuickSight validates your asset definition when you create or update analyses, dashboards, and templates via the API using definition objects. With STRICT (the default), every validation error is enforced, and the API call will fail if any issue is found. With LENIENT, validation is skipped for specific non-critical UI errors, meaning cosmetic or layout issues that don’t break data or functionality won’t block the request.
The main use case for LENIENT is CI/CD pipelines and programmatic migrations (e.g., deploying across accounts via CloudFormation or Asset Bundle import/export), where minor visual validation warnings shouldn’t halt an automated deployment. Best practice is to use STRICT during development to catch issues early, and LENIENT in automated pipelines where you’ll review the assets visually after deployment.
Hi @JacobR, thanks for the help. I get that part but i was more-so interested in the specific differences between the UI and the API in this case.
In our use-case, we basically have an analysis that is edited/created through the UI. However when it’s time to publish said analysis, we publish it through the API (which might have STRICT validation mode). So like you mentioned, its not just one or the other in our case. We have a mix of both strategies.
So its very important for us to know if the UI can every silently swallow some errors the only time you basically find out is during a publish attempt. Do you have any info on this case?
Also, when you say “Skipped over”, is the whole validation step skipped or just the act of raising an exception once some validation step fails? So do you get a performance boost by using LENIENT basically.
Based on further research, here is what I can piece together:
1. Can the UI silently accept things that STRICT mode rejects?
Short answer: yes. The QuickSight console is more permissive than the API when it comes to validation. You can save and publish analyses in the UI that contain things like invalid calculated field expressions, broken conditional formatting, or references to columns that no longer exist in the dataset. The UI just… works around it. But when you go to publish that same asset via the API with STRICT validation, those issues surface as hard failures (INVALID_CALCULATED_COLUMN_EXPRESSION, INVALID_CONDITIONAL_FORMATTING_EXPRESSION, etc.).
So for your workflow specifically (edit in UI, publish via API with STRICT), yes, you can absolutely hit errors at publish time that the UI never told you about. I believe this is still being reported and the behavior hasn’t changed (Analysis or Dashboard Definition Validation - Q&A - Amazon Quick Community).
One thing you can do: call describe-analysis-definition and check the Errors array in the response before attempting your publish (DescribeAnalysisDefinition - Amazon Quick Sight). That’ll surface issues proactively. Alternatively, you could use LENIENT for the publish step itself to match the UI’s tolerance, but then you’d want some other mechanism to catch real problems.
2. Does LENIENT skip validation entirely / is there a performance boost?
In this docs it says “validation is skipped for specific UI errors.” That’s the full extent of what’s documented. It doesn’t elaborate on whether the underlying checks still execute (with errors suppressed) or whether those checks are bypassed entirely, so I can’t confirm either way. I also couldn’t find anything in the documentation about a performance difference between the two modes.
Just wanted to check in this thread and see if Jacob’s most recent reply assisted you. Please help the community by marking this answer as “Solution” or following up in general within the next 3 business days!
Since I haven’t received any further updates from you, I’ll treat this inquiry as complete for now. If you have any additional questions, feel free to create a new post in the community and link this discussion for context.