Idea Summary
Every application import disables all Automations and REST Data Source sync jobs in the target app. Activation is runtime state the import does not honor — even when the APEXlang source carries scheduleStatus: active / jobIsActive: true, the jobs arrive disabled. There is currently no declarative, version-controlled way to say which jobs should be active in which environment; teams must maintain hand-rolled post-import scripts calling apex_automation.enable and apex_rest_source_sync.enable inside an apex_session.create_session context, or production scheduled work silently stops.

Use Case
We version-control an ~800-page production application as APEXlang and deploy by import. After promoting a release, all 24 production automations (price feeds, syncs, notifications) and 19 REST source sync jobs were silently disabled — nothing failed, the feeds just stopped. The same applies to every routine deployment on any app that has scheduled jobs. Conversely, development copies of the app should NOT run those jobs — so a single "preserve activation" flag isn't enough either: activation is genuinely per-environment configuration.

Preferred Solution (Optional)
Extend the APEXlang deployments/*.json files to declare activation state per environment, applied at import — e.g. "automations": {"active": ["fetch-daily-prices", "rollover-fundings"]} and the same for REST source sync modules, keyed by static ID. dev.json lists none; prod.json lists the curated set. This makes activation intentional, environment-aware, reviewable in Git, and removes an entire class of silent production outages..