Integration Services Multitenants


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.


Hello @bram.vanheuvelen ,

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.

Looking forward to any suggestions.

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.


Could this be a bug or are we missing a key configuration step when it comes to Unattended Automations?


And Welcome to the community @Wendy_Beekman ! :+1:

Hi @Wendy_Beekman,

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.

Running the process as Unattended was straight forward:

As seen below, one run succeeded and the other is currently in Running:

Machine Template/User Setup:

I’m connected in Unattended mode using a Machine Key of a template I created specifically for this purpose.

Note that although the Orange beacon indicates I’m Connected/Unlicensed, the Automations when triggered from Orchestrator are visible only when they are running! :neutral_face:

I hope this helps.


This is the user setup assigned to the /Shared folder with an Automation User role:

Package Dependencies:

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.

1 Like

Hi @AndyMenon,

Thank you for the very detailed explanation!

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’

We will test if changing our configuration to a local user account will prevent the error. (test results will follow)

But at the end I still hope to figure out if the Integration Services will work also with a Robot account in unattended mode.

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.

And I just got the same result.

  1. I set up a dedicated modern folder with it’s own feed
  2. Deployed the automation to this modern folder
  3. 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.

Late reply :sweat_smile:

I’m not sure if this was the case then, but on the page about connectors there is a small note:

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 ! :joy:

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).

1 Like

Sweet! Looking forward to it!

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.

Any progress on this?


It’s a few months later… Any update? :slight_smile: