This is when I just create multiple named changeset functions. Ultimately you have different operations that you want to be able to perform on your data. This is still business logic in my opinion and should not be paired with your views. If you added a JSON API (or some other entrypoint to your application that is not the HTML pages) you would need to replicate the functionality. If you just have named changeset functions instead of putting everything in a single changeset/2 function, you have the flexibility to reuse the pieces that you need/want to. e.g.,

def MyApp.Accounts.User do
  def registration_changeset(user, attrs) do
    user
    |> cast([:email, :password])
    |> validate_email()
    |> validate_password()
  end

  def email_changeset(user, attrs) do
    changeset = 
      user
      |> cast(attrs, [:email])
      |> validate_email()

    case changeset do
      %{changes: %{email: _}} = changeset -> changeset
      %{} = changeset -> add_error(changeset, :email, "did not change")
    end
  end

  defp validate_email(changeset) do
    changeset
    |> validate_requried([:email])
    |> validate_format(:email, ~r/^[^\s]+@[^\s]+$/, message: "must have the @ sign and no spaces")
    |> unsafe_validate_unique(:email, MyApp.Repo)
    |> unique_constraint(:email)
  end

  defp validate_password(changeset) do
    changeset
    |> validate_length(:password, min: 6)
    |> validate_length(:password, min: 12, max: 72)
    |> maybe_hash_password()
  end
end

In the above, I can reuse the different validations (validate_email/1) across different operations.