Skip to Main Content
Status Future consideration
Categories Account settings
Created by Guest
Created on Feb 21, 2017

Dedicated Integration User

It would be great to have a dedicated integration user instead of having to use a user license for this purpose.  I would love to keep my user and the updates from integrations (Jira, TFS,...etc) separate so that it is clear who made the update in Aha. To do this today I would need to buy another license for integrations and I don't think that should be the case. 

  • Attach files
  • Guest
    Nov 8, 2022

    This is causing issues at my workplace, too. It isn't right that we would have to pay for a full license just to have an integration user.

  • Tessa Adair
    Mar 2, 2022

    It's really disappointing that this isn't supported. In my experience, it’s standard practice that we’d be able to create a service account for this sort of thing without paying for another full user license which is a large expense disproportionate with the value we’d get. In other words, you’re requiring a “seat” license for something that doesn’t actually represent another “seat”.

    Furthermore, even if we were able to pay for another license for this purpose, it would still not be following security best practices! Integration users should be limited to the specific kinds of calls an integration can do, so you should allow us to use a service principal instead of a real user for this.

  • Guest
    Apr 12, 2021

    I completely agree with Cyril. When using a "real" Aha user for the integration it is very confusing as they are not the ones making the changes, but rather automatic updates from Jira. As others have done, we created a specific Jira integration user for this purpose, but that requires a full license. There ought to be another user type such as "integration" user which is either free like observers or at a steep discount from full users since this user won't actually be logging in through the UI

  • Cyril Bousquet
    Jul 15, 2020

    Agreed. This is creating a lot of confusion within my teams and even setting individual PMs for the integrations, they are not the ones always making the changes in JIRA so it is also confusing to them as they see changes landing in Aha! that they do not understand.

    Notifications via emails are also confusing and my users have started disabling Aha! notifications as they raise more questions than answers.

  • John Biltcliffe
    Feb 12, 2020

    We are struggling with multiple integrations to our Jira system running under different accounts.  It would be much easier to maintain if they were running outside of the user space as a proper service

  • Laura Giles
    Oct 23, 2018

    Agree. SFDC has this ability.

  • Guest
    May 17, 2018

    My use case is slightly different but I agree this would be beneficial. I am the only paid user with my current plan and I have a zendesk integration setup. Even after going through the steps to ensure Im a watcher and to enable notifications, I still cant get notifications for ideas submitted through our zendesk integration. This is because Im the user who authenticated the zendesk aha integration and Im told it thinks Im the one submitting the request so it doesnt email me.

  • Guest
    May 4, 2018

    It can be very confusing for our team to see "The boss did this, the boss did that".  Creating a service account named "Github Activity" makes things much clearer.


    I can see an "API Only" user being a feature of an Enterprise plan.



System account for API access

As an Enterprise+ customer, I'd like Aha to offer a system account that's specifically for API usage. I don't want to swap API keys if an employee terminates. I'm also not eager to use a paid seat exclusively for API access. Perhaps this would bec...
Brian Trombley about 2 years ago in Integrations 0 Future consideration

Using a single user for integrations

Please can you make an option to have a single user for integration (integration only) ? We are making this a standard setup and due to security of an individuals password, we didn't want to use a "real user". Unfortunate this means that we are bi...
Guest over 5 years ago in Integrations 0 Future consideration