There are various ways that you can back an Ash resource with custom functional behavior. They are kind of like “tiers” of levels of escaping/overriding the framework’s behavior. In ascending order of what you should choose to use based on what you need.

• Calculations and aggregates: computed properties that can be loaded on demand

• Changes, Validations, Preparations: Attach functional behavior to an action, but keep the data layer default behavior. Great for attaching custom logic.

• Ash.Changeset.set_result or Ash.Query.set_result. If you want to conditionally override the result of an action, but in other cases, use the default action behavior, you can set the result of the action in a change/preparation. This can be used for things like providing a cached response conditionally. Here is a real example: ash_hq/lib/ash_hq/docs/resources/library/preparations/check_cache.ex at main · ash-project/ash_hq · GitHub

• Manual Actions/Manual relationships: This allows you to keep the semantics of the action (i.e honor any changes, validations, hooks) but decide how the action itself is committed. This can be used with resources that have no data layer implementation as well.

This isn’t exhaustive, but its a good indication of the various levels of escape hatches, and the methodology of progressively selecting the least intrusive one that will accomplish what you need to accomplish.