Errors and remedies
Blueprint errors describe what failed and, when available, how to recover. Show the explanation close to the action or field that caused it.
Common situations
| Situation | What to do |
|---|---|
| A field is invalid | Correct the indicated value and submit again. |
| An action is not allowed in the current state | Refresh the record and check its available actions. |
| Access is denied | Check the signed-in account and its grants. |
| A record changed while being edited | Refresh it and review your changes before retrying. |
| A service is temporarily unavailable | Retry when the error says retrying is supported. |
| A required integration is missing | Check the application's server configuration. |
Keep useful context
Preserve the error code and any request or trace identifier when reporting a problem. They help the application operator find the matching server log.
Do not treat failed requests as empty results or successful changes. Keep user input available when a retry is possible.
Describe business errors
Declare application errors alongside actions and rules so clients can show consistent messages. Use clear descriptions such as “Equipment must be cleaned before approval” rather than implementation terms.