You can choose where to put new and imported profiles via burger menu > Global Settings > Settings tab in V9 (or newer) version (or Preferences > Options menu > Settings tab).
With SyncBackPro/SE V9 (or newer) version, it is possible to specify a folder to store the profiles under:
burger menu > Global Settings > Settings > 'A specific folder' setting
With SyncBackPro/SE V8 (or older) version configure a specific folder under:
Preferences > Options > Settings > 'The folder to use for Profile settings'
Optionally, you can enable the option 'Only Use this folder for settings. Do not use other folders' to use profiles stored only in that specific folder (but not from the default storage location). Note the above option is not supported in SyncBackFree.
To move an existing profile you must export it, delete it, change the setting where to put new profiles as appropriate, then re-import it. Do not omit the 'delete' step or you will finish with profiles of the same name in both locations and errors and/or unexpected behavior will arise.
Note that you should always import group profiles last, i.e. import the profiles in a group before Importing the group. If you do not, any empty groups (with no member profiles or sub-groups yet imported) will immediately self-delete as part of the internal housekeeping. You can recover from this by Importing just the group profiles again. If you have nested groups, you should Import them in the order 'inner' to 'outer' for the same reason.
If you set the profile storage location to 'The same directory as the program', this may be so that all users can see/run the profiles. If so, you may wish to make arrangements so that all users can also see the logs (regardless of who ran the profile/s). To do so, you should also log in as each user who will run the profiles and set the log settings (burger menu > Global Settings > Logging Settings tab in V9 (or newer) (or Preferences menu > Log Settings in V8 (or older) version) to a common-shared area (you can pick any common location for this, but obviously avoid user-based Variables). If you do not do this, you will get errors when logged-in as user-B trying to view logs created 'as' user-A (the default logging uses a user-based variable, and the log index will contain the same variable, which will evaluate wrongly if/when a different user is logged in)
Note that even if you do change the log-storage for each user, any previous logs will still only be visible to the user who ran the profiles. This situation will eventually resolve itself as new logs are stored (in the new location) and old ones automatically deleted.
Another caveat if you set the profile storage to 'The same directory as the program' , so that all users can see/run the profiles, is that you need to grant full access to the program folder for all such users, which they probably do not currently have (especially in later versions of Windows). Profiles self-update with LastRun (etc) info and thus need whoever is running them to be able to effect file changes in the area they are stored. If the program detects you do not have write access to that area, the option to use it is disabled.
Finally, bear in mind that any Schedules may (depending on your OS, thus the Windows Task Scheduler version concerned) be stored 'per user', so you may not be able to see/edit any Scheduled Tasks set up for a centrally-stored profile by another user. Beware of inadvertently setting up multiple Schedules for the same profile under different user names (especially for the same time...). Conflicts and unexpected aborts can arise, as each instance of the profile will check for a running instance, and can be confused by other instances starting simultaneously.