The 4D Server reference lays out the rules for set scope when sets are created in client-server:

https://doc.4d.com/4D%20Serverv12/help/Title/en/page317.html

It is important to understand the ramifications of set scope on application performance. In particular the scope of each set type speaks directly to how it affects network load; i.e. the bottleneck for set performance is network operations, if they are invoked. Sets are otherwise VERY fast and efficient.

Local and interprocess sets reside only on the client. CREATE EMPTY SET, ADD TO SET, REMOVE FROM SET, and set operations do not trigger any request to the server. Obviously, USE SET will make a network request since it creates a selection; selections live on the server, never the client.

Process sets, on the other hand, send a request to the server every single time they are modified: create, add to, remove from, and clear. If a COPY SET command acts on a process set, it also generates a network request. The goal of using process sets is to get the set in the execution context of the cooperative "twin" process on the server (the set can then be used in a trigger or in the context of methods with the "Execute on server" attribute).

Important Note: the set that is bound to a List Box with a selection data source is a process set by default. This can be changed to a local or interprocess set by modifying the set name: