reactor works with the concept producerand consumer. The consumer subscribes to the producer and nothing will happen until you subscribe.
When using webflux, which is basically spring-web but implemented with reactor the concept goes that the final consumer is usually the one subscribing.
You can think of it as the database is the producer and the calling client (webpage, react app, mobile app) is the consumerand when the client initiates a call to the backend, the client subscribesto your serverand the serverin turn subscribes to the database(remember? producer, the database produces data).
So your server is basically just forwarding the data to the calling client, which means that usually you just take the data and return it out to the client, and the framework will handle the "subscription", automatically.
Which usually means, you should NOT subscribe in your application, instead, you should chain on the calls, and always keep the chain intact so that your server can produce items to the client.
So when should you subscribe in your server?
Well one reason could be that you have a running job in your server that maybe fetches data from one server and inserts it into it's database. Then your service is the initiating client, subscribing to another server, the other server produces items to you, you receive them and insert them into your database.
but for instance in your example:
// first we fetch all, we filter, then we save, and we return back to the calling client keeping the chain intact, and no subscriptions
return reactiverepository.findAll()
.filter(employes -> //some criteria)
.flatMap(employee -> reactiverepository.save(employee));