Strategy Design Pattern - How many algorhithms are too many?

I'm about to implement the strategy design pattern into my project to handle all the different behaviors based on the user's role. For a simple example, I have a method to fetch all the orders in the system, like getOrders().

There are about 8 different roles in the system, and most of them are handled differently. For instance, some users are only allowed to see certain orders. Some can see all, or some can see only the ones that belong to them. Before, I used to use one method in a "service class" and would conditionally check there. The example is just one method, but it really happens throughout the system for data retrieval. So I thought it would be cleaner if I extracted those conditional methods into a separate class, which can be switched out depending on their role. So each class would have that getOrders() method, and I can define it for each role.

Now, does that sound like a feasible way to do this? Is there a general upper limit of classes I should be aware of, before deciding that there might be a better way to handle this?

I also thought about combining the decorator pattern as well. Not to go on a tangent, but I believe this would allow me to let manager roles to get everything their subordinates have, by decorating what they already have implemented, and then adding on if needed.

On a side note, I'm using Laravel and was going to switch out the classes by binding the concrete implementation in the AppServiceProvider.

Any input would be great, thanks!