# High-Value Management Angles The most promising Synology automation surfaces are the ones that already expose a meaningful control loop: inspect state, change it, and often track asynchronous completion. That makes them much more valuable than namespaces that only return status. One nuance from the upstream source audit is that some strong control domains are underdocumented rather than absent, especially Docker and Virtualization.[^core-user][^core-package][^docker-source][^filestation][^cloudsync][^surveillance][^virtualization][^docs-status] ## 1. Identity and access governance This is one of the clearest "real admin control" zones: - local user CRUD - local group CRUD - user-to-group assignment - password policy and expiry policy - share permissions and group quotas[^core-user][^core-group][^core-share] This suggests immediate research value in workflows like onboarding/offboarding, access hardening, and storage-governance automation. It is also a good place to ask where confirmation tokens, elevated permissions, or destructive safeguards are required.[^core-user][^task-scheduler] ## 2. Storage operations and data movement Synology looks especially strong where file movement and storage topology meet: - shared folder lifecycle, encryption, and permissions - FileStation upload/copy/move/delete/share-link operations - Download Station task lifecycle and scheduling - Cloud Sync connection/task/schedule/filter control[^core-share][^filestation][^downloadstation][^cloudsync] This cluster is management-relevant because it goes beyond observability into policy, placement, and movement of data. It likely supports useful admin workflows like staging, archival, controlled external sharing, sync throttling, and scheduled ingest/export. ## 3. Platform lifecycle and maintenance Package Center, task scheduling, event scheduling, power schedules, and certificate operations form a strong operational-control layer: - package install/upgrade/uninstall/settings - scheduled script execution - boot/shutdown-triggered tasks - power-on/power-off schedules - certificate upload/default/service-assignment workflows[^core-package][^task-scheduler][^event-scheduler][^certificate] This is the closest thing to a native orchestration plane inside DSM. It deserves deeper follow-up around guardrails, idempotency, task output capture, and whether privileged operations require explicit password confirmation tokens.[^core-user][^task-scheduler] ## 4. Container and VM operations deserve a separate lane The source audit changed the picture here: - Docker / Container Manager is implemented as a broad `SYNO.Docker.*` control surface upstream, including container, image, network, registry, and compose-project lifecycle coverage.[^docker-source][^docs-status] - Virtualization / VMM is source-implemented even though its upstream docs status is still `not_started`.[^virtualization][^docs-status] These are high-value if your NAS is running application workloads, but they should be treated as a **source-driven** research lane because the docs trail the implementation. ## 5. Surveillance as a first-class control plane Surveillance Station is unusually rich: - camera provisioning and updates - enable/disable cameras - PTZ motion and preset operations - motion/tamper/digital-input tuning - recording and event deletion/locking flows[^surveillance] This is clearly more than observability. It looks like a real device and recording operations surface, which means it belongs near the top of any "what can I actually control?" answer. ## 6. High-risk surfaces worth separate treatment Some domains matter because of blast radius, not breadth: - package install/uninstall - share permission changes - encrypted-share lock/unlock - recording deletion - shutdown/reboot - task execution as root-like owners - VM and container lifecycle actions on live services[^core-package][^core-share][^surveillance][^core-sysinfo][^task-scheduler][^event-scheduler][^docker-source][^virtualization] These should be tracked separately in the eventual report as **destructive or high-consequence** control surfaces, since they shape what safe automation can look like. ## 7. Next research cuts The next highest-yield follow-ups are: 1. direct DSM API potential for Drive Admin, KeyManager, OAuth, and Log Center write operations 2. snapshot, backup, and virtualization validation where docs are incomplete or absent 3. safety patterns for high-risk actions 4. a shortlist of first automation workflows to prototype from the already-exposed control surfaces See [[wrapper-gaps-and-direct-api-candidates]] and [[implementation-vs-doc-status]] for the first two of those tracks.[^drive-admin][^snapshot][^docs-status] [^core-user]: Core User docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_user [^core-group]: Core Group docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_group [^core-share]: Core Share docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_share [^core-package]: Core Package docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_package [^task-scheduler]: Task Scheduler docs: https://n4s4.github.io/synology-api/docs/apis/classes/task_scheduler [^event-scheduler]: Event Scheduler docs: https://n4s4.github.io/synology-api/docs/apis/classes/event_scheduler [^certificate]: Certificate source entrypoint: https://github.com/N4S4/synology-api/blob/master/synology_api/core_certificate.py [^docs-status]: Upstream documentation status tracker: https://github.com/N4S4/synology-api/blob/master/docs_status.yaml [^docker-source]: Docker source entrypoint: https://github.com/N4S4/synology-api/blob/master/synology_api/docker_api.py [^filestation]: FileStation docs: https://n4s4.github.io/synology-api/docs/apis/classes/filestation [^downloadstation]: Download Station docs: https://n4s4.github.io/synology-api/docs/apis/classes/downloadstation [^cloudsync]: Cloud Sync docs: https://n4s4.github.io/synology-api/docs/apis/classes/cloud_sync [^surveillance]: Surveillance Station docs: https://n4s4.github.io/synology-api/docs/apis/classes/surveillancestation [^core-sysinfo]: Core SysInfo docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_sys_info [^drive-admin]: Drive Admin Console docs: https://n4s4.github.io/synology-api/docs/apis/classes/drive_admin_console [^snapshot]: Snapshot docs: https://n4s4.github.io/synology-api/docs/apis/classes/snapshot [^virtualization]: Virtualization source entrypoint: https://github.com/N4S4/synology-api/blob/master/synology_api/virtualization.py