Is your feature request related to a problem? Please describe.
Today, business rules like “this mutation is only allowed when the current item matches a condition” must be implemented with custom resolvers. This adds extra complexity for common use cases.
For example, we may have a Contract model with a status field. An updateContract operation should only be allowed when the current status is OPEN. While clients can send conditions, this is not enough as a security and data integrity measure, because a user with a valid token could bypass the app and send GraphQL requests directly.
A more advanced example is state transition validation. For example, a contract should be allowed to move from OPEN to SUBMITTED or from SUBMITTED to APPROVED, but not from APPROVED back to OPEN. Today, this requires custom resolver or Lambda logic.
Describe the solution you'd like
It would be helpful if Amplify Data supported model-level or operation-level conditions that are automatically enforced in the generated resolvers and passed to the underlying DynamoDB operations.
For example:
updateContract is only allowed if status = OPEN- or more specifically, a status update is only allowed for defined transitions such as
OPEN -> SUBMITTED and SUBMITTED -> APPROVED
It could also be useful for queries. For example:
- only return
Contract items where status = OPEN
- only return items where
isDeleted = false
This would allow common business rules to be enforced at the data layer without requiring custom resolvers for each case.
Describe alternatives you've considered
The current alternative is to disable the generated operation and implement a custom resolver, custom mutation, or Lambda-based logic. This works, but it removes part of the benefit of the generated Amplify Data API for cases that are relatively common.
Additional context
The main goal is to support business-rule-based validation and filtering on the data layer, not only on the client layer. This would help protect against direct GraphQL calls that bypass client-side checks, while keeping the generated Amplify Data workflow simple.
Is your feature request related to a problem? Please describe.
Today, business rules like “this mutation is only allowed when the current item matches a condition” must be implemented with custom resolvers. This adds extra complexity for common use cases.
For example, we may have a
Contractmodel with astatusfield. AnupdateContractoperation should only be allowed when the currentstatusisOPEN. While clients can send conditions, this is not enough as a security and data integrity measure, because a user with a valid token could bypass the app and send GraphQL requests directly.A more advanced example is state transition validation. For example, a contract should be allowed to move from
OPENtoSUBMITTEDor fromSUBMITTEDtoAPPROVED, but not fromAPPROVEDback toOPEN. Today, this requires custom resolver or Lambda logic.Describe the solution you'd like
It would be helpful if Amplify Data supported model-level or operation-level conditions that are automatically enforced in the generated resolvers and passed to the underlying DynamoDB operations.
For example:
updateContractis only allowed ifstatus = OPENOPEN -> SUBMITTEDandSUBMITTED -> APPROVEDIt could also be useful for queries. For example:
Contractitems wherestatus = OPENisDeleted = falseThis would allow common business rules to be enforced at the data layer without requiring custom resolvers for each case.
Describe alternatives you've considered
The current alternative is to disable the generated operation and implement a custom resolver, custom mutation, or Lambda-based logic. This works, but it removes part of the benefit of the generated Amplify Data API for cases that are relatively common.
Additional context
The main goal is to support business-rule-based validation and filtering on the data layer, not only on the client layer. This would help protect against direct GraphQL calls that bypass client-side checks, while keeping the generated Amplify Data workflow simple.