There are two key ways to establish shared folders on an Arbutus Windows Server for scheduling jobs.
The first is independently, provided the work in each shared folder is self contained - that is to say, work in one shared folder makes no reference to work in another shared folder. This means that a job scheduled in the shared folder has no dependency on objects in another shared folder.
The second is "encapsulated", where one or more shared folders are subordinate to a "primary" shared folder. This is because, most commonly, when using multiple shared folders, there is an inherent dependency between these shared folders. For example, when performing a regularly scheduled Extract Transform and Load (ETL) process to feed data to various groups - possibly regionally - through a common set of master processes. In this example, an administrator should set up one or more scheduled procedures to create and load the data necessary for each region to subsequently analyze. The administrator would store these procedures in a "primary" shared folder on the Arbutus Windows Server (say "Load_Data") that only the administrator has access to. Then shared folders for each region would be established as sub-folders to the primary "Load_Data" shared folder for each region (say "Region1, Region2, etc..."). In this way the administrator sees all data in the primary shared folder and all of its sub-folders and can easily update data using the master procedures in any of these sub-folders. End-users however, would establish a shared regional folder that is mapped to the appropriate regional sub-folder. This means end-users would only see data and objects relevant to their specific region and could not see data or objects for other regions or within the administrators primary shared folder.
Additionally, users should only be granted read/write access to shared folders if they plan to schedule jobs and place the scheduled results into the shared folder for use by other users (by default, all results are placed in the Output Prefix specified in the individual user's Server Profile to which the user always has read/write access). Otherwise the users would only need to be granted read access to the shared folder. This simplifies shared folder management for the administrator.
So in short, if you have the need to create multiple shared folders that are self-contained and scheduled jobs within them do not rely on content in other shared folders, then the shared folders can be established independently on the same Arbutus Windows Server (even at the same folder level).
However, if you have the need to create multiple shared folders that are inter-dependent and scheduled jobs within them rely on content in other shared folders, then the best practice is to establish a main or primary shared folder with sub-ordinate shared folders established as sub-folders below the primary shared folder.
For more information on scheduling jobs, see Scheduling Procedures.