Oficialmente, você não tem controle sobre a ordem das operações em cascata. Você pode abusar de alguns não documentados comportamento no entanto:

• para MySQL 5.5, as chaves estrangeiras são executadas na ordem em que foram criadas, portanto, descartando e recriando o fk_category_org -a restrição deve funcionar
• para MySQL 5.6+, as chaves estrangeiras são executadas na ordem lexical de seus nomes, então renomeando fk_category_org para, por exemplo, fk_z_category_org deve funcionar

Isso não está documentado e pode mudar a qualquer momento (e pode ser influenciado por outros fatores).

Dito isto, a maneira correta de fazer isso (e qualquer outra coisa muito complicada para on cascade ) seria adicionar um before delete -trigger na sua organisation -table que "manualmente" exclui os usuários primeiro e depois as categorias. before delete -triggers são executados antes de on cascade (para que você possa decidir se deseja mantê-los ou não, embora provavelmente seja enganoso).

Não está totalmente claro se esse é o seu comportamento pretendido, mas atualmente, um usuário pode ter uma categoria que pertence à organização 1 enquanto ele está atribuído à organização 2. A exclusão da organização 1 ainda falharia. Parece que é isso que você quer evitar pelo seu design, mas se você quiser que a exclusão funcione também neste caso, você precisa para usar o gatilho para poder incorporá-lo (ou excluí-lo manualmente em seu aplicativo), a cascata não funcionará a menos que você também faça a cascata na tabela de categorias.