noob96,

Задание агента можно запустить через sp_start_job
название задания можно из подписок/расписания брать (напр. по названию подписки и названию/пути файла в PBI/SSRS, у PBIX тип=13)
или если не охота (или по к-либо причинам не подходит) одно задание агента вызывать из другого (не трогая оригинальную подписку/расписание)
то можно параметры в процедуру dbo.AddEvent из запроса цеплять:

(можно почистить от лишних join-ов если не все поля нужны)
расписания/подписки не генерируются каждый раз снова - изменения накладываются на их старые IDшники
так что если расписание не удалять а просто изменить (время срабатывания через SSRS/PBI интерфейс) - то ничего не слетит.

noob96,

Не вижу проблемы если честно - SOAP/REST API есть и у обычного SSRS который On-Premise,
(авторизация это немного другой вопрос, т.е. под каким пользователем Агент Job запускает,
в тот-же скрипт можно строку определяющую текущего пользователя для лога добавить ради проверки на всякий случай)

как-то делал совсем недавно PowerShell автоматизацию SSRS/Power BI Report Server на SOAP/REST API
для PBIX файлов Download/Upload функциональности ( через ReportService2010.asmx ),

{на тот момент было проще, т.к. content поле в DB у них в таблице Catalog для Power BI
файлов было пустым/null, в последней (январской -2020) версии смотрю - оказывается
есть в CatalogItemExtendedContent , но уже решение в Live ..}

так там видел что есть FireEvent метод (и авторизацию прописать можно),
https://docs.microsoft.com/en-us/dotnet/api/reportservice2010.reportingservice2010.fireevent?view=sqlserver-2016
туда конечно тоже SubscriptionID (с проверкой/синхронизацией по имени для надёжности)
параметром вставлять (как и в AddEvent),
который можно вытащить через привязку к нужному отчёту {через тот-же SOAP, или запрос выше}
(все подписки/расписания, последнее для статичности может пыть одноразовым без удаления)
на этот обьект (по имени/пути файла/отчёта в структуре)