In my dev tenant, I’m using the Integration Services for FreshService, with my personal development account. It’s working fine.
I also created the same connection with the same account in PD-tenant.
After publishing the package to Dev-tenant, downloading it, and uploading it to my PD-tenant, the process will not work because the robot uses its own robot-account.
With that robot-account, I can’t create an Integration Service connection, as it is no regular user and cannot log in to orchestrator.
Is there an option to create a connection for a robot account? Or does anybody wat the correct way is to make this work?
Last option is offcourse using regular http request, but really want to make the Integration Services work between tenants.
Did you set the connections in PD-tenant as Default?
If I understand this right, you have to have an integration service connection created in your deployment environment and if that is set to Default, the Robot always uses that Default connection for that scope.
We did set the connection as default. However this was done in a personal automation cloud account for both development Tenant as Production Tenant. Those connections are also not visible for colleague developers. Is this expected behaviour?
But especially we are wondering how to share those default connections with the unattended robot account, since this account uses access by machine key.
When we run our project unattended on the production VM we will receive the error message:
”The Integration Service is not enabled for your tenant or not available, but the activity is configured to use it.”
Since we did enabled the integration service functionality in the tenant setting, we are wondering what or which settings are needed to make the service also available fur the unattended robot.
Actually, per my understanding, the Integration Service is a feature that exists at the Automation Cloud level which sits above the Orchestrator tenants. Therefore, a connection when set as Default must be available to automations during run time.
This is the second instance I am hearing about the same issue as far as Unattended automations are concerned. I tested this out by running an Attended Automation and it worked without a hitch.
I’m yet to test this with an Unattended automation to see if I run into the same problem.
Have you tried to run this as an Attended Automation? If the same automation that fails as Unattended works as Attended when deployed to Orchestrator, it might mean that something in the system that triggers unattended automations is missing or isn’t working the way it should.
This is detailed, but I’m going to post the set up on my end in the hope that the community finds it helpful.
I was able to run the Automation that uses integration with Google Sheets and Drive as Unattended Automation without any issues.
The package was deployed to the Shared folder and when setting up the process, the deployment did recognize the integration service connections used in the package, although I still find the message at 3 below a bit puzzling.
Note that although the Orange beacon indicates I’m Connected/Unlicensed, the Automations when triggered from Orchestrator are visible only when they are running!
Lastly, this automation was built at least 2 months ago when I posted a video on my YouTube channel about this topic. Here below is a list of the dependencies used at that time. I’m posting this here in case, any of these dependencies are contributing to the issue on your end.
Our set-up/configuration is almost identical than yours.
Similarities are the dependencies versions in the project, the setup of the process in shared folder, the use of a machine Key and the way we start a unattended job from orchestrator.
The only and probably essential difference is the account we use for unattended mode.
We use:
Type: ‘Robot account’, Robot Type: ‘Unattended’, Roles: ‘Robot’
While you use:
Type: ‘Local user’, Robot Type: ‘Attended/Unattended’, Roles: ‘Automation User’
The integration service does work successful in attended mode using my personal account of type local user on development tenant. I also set in my personal account in orchestrator the default connections and hence it works.
However since we use a robot account for unattended mode on production, we have to figure out how to configure the default connections for this robot account. First impression is that the connections we create are only on personal level and not visible/usable for other (local)user and robot accounts.
This is correct. The current implementation is for personal connections only, which means one would have to activate those connections for the users that actually run the automations to make it work (and even then it might be a bit gimmicky).
This is something that our Integration Service team is working on improving in future versions.
I set up a dedicated modern folder with it’s own feed
Deployed the automation to this modern folder
Created & Assigned a Robot Account with Robot Role
The automation failed with the same error @Wendy_Beekman has run into.
Repeated the test by changing the Roles of the Robot account as “Automation Users” role and “Allow to be Automation Users” at the Tenant level.
No difference.
@loginerror - this is good to know.
Is this something that is in the Integration Services documentation? If yes, then we missed it. If not, having it added will be definitely helpful.
I hope I understood this right. I thought I heard this during our initial discussions and demos on Integration services. But I wasn’t sure. That is severely limiting then! Do we then have to set the connection once when doing UAT, and then open it up again after passing UAT and repurpose it for a different user+platform? I’m thinking how can this ever be possible in terms of real world practice? I’m saying this because once code is frozen, how can the package be repurposed to work with the IS connection on the PROD instance?
In most COEs, the Dev team will not have access to the PROD instance. They can deploy packages, but I am not entirely sure who would change the connections out so that the Integration Services connection aligns to the PROD user+tenant?
As for the note, It should be in big letters !
We should still meet. For some reason, none of my Unattended Automations are kicking in . Instead they are all going into Pending state despite the fact that the Unattended runtime is assigned to only one template. Not sure why this is happening.
This is why our team is already working on Shared Connections to solve this issue (it should be hopefully coming in one of the upcoming community releases first).
Any updates or timeframe on this? Since microsoft is deprecating basic auth for exchange on October 1st, this could be an amazing way to interact with microsoft 365 mails instead.
ashokkarale
anjani_priya
Dheerendra_vishwakarma
Parvathy
Aakash_Singh_Rawat
Luis_Fernando
bjorn2390
neco
pere
Shiva_Nikhil