How to execute scheduled job by fetching domain specific credentials?

[bachhav]

I have a scoped app that supports MSP. The scheduled job is bundled with the app as a global domain scope. The app has credentials, connection aliases, and HTTPS connection records for each domain. The app script fetches the current domain and the connection and credentials of that domain to fetch the domain-specific records from the table. 

When a scheduled job is executed, it's executed as sys_user, so it cannot fetch the domain ID of the logged-in user. The function is unable to fetch the domain-specific records from the table as the domain ID is not available.

How to get the domain ID of the current logged-in user while executing a scheduled job for a particular domain?
How to set a different scheduled frequency for each domain for the scheduled job that is bundled with scoped app global domain?

[SD_Chandan]

hi @bachhav 

Get Domain ID in Scheduled Job:

Use gs.setCurrentDomainId(domainId) to set domain context manually.
Fetch domain ID from a config/custom table.

or
Use Domain Delegation or Domain Separation APIs to dynamically manage domain-specific logic and credentials.

[bachhav]

Hi @SD_Chandan,

My questions are:
How to get the domain ID of the current logged-in user while executing a scheduled job for a particular domain?
How can I set a different scheduled frequency for each domain for the scheduled job that is bundled with the scoped app global domain? 

The above solution is to get the Domain ID in a scheduled job. Please elaborate more on it. 

[SD_Chandan]

1. Get Domain ID in Scheduled Job
Scheduled jobs run as the system user, not a logged-in user. To get domain-specific data:

Loop through the domain table.
Use sys_domain field in GlideRecord queries.
Optionally use GlideDomainSupport.getCurrentDomainId() if available.
2. Set Different Frequencies per Domain
You can't set multiple frequencies in one job. Instead:

Option A: Create separate scheduled jobs for each domain with different schedules.
Option B: Use one master job that runs frequently and checks per-domain last run time (stored in a custom table or property) to decide whether to execute logic.