Skip to Main Content
152 VOTE
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
  • Ali Rizvi
    Reply
    |
    Feb 12, 2024

    We are facing the same problem as Rob S mentioned below. I am the owner of our integration between ADO and Aha!, and I am constantly being asked by my colleagues as to why I have changed their features/tickets. This is not ideal. Rather than forcing the customer to lose a user license for an integration user (one that will not be used for productive login/web app usage), it would be better if there is a system user (UI login disabled) that can be used for webhooks between Aha! and other systems. If revenue/costs is an issue for Aha! here, then integration users should be sold separately.

  • Rob S
    Reply
    |
    Feb 1, 2024

    I have the same problem. The integration is currently running in my name and I'm getting a constant barrage of questions about why I've updated other people's tickets and enquiries from others into the work completed. I have no idea - I run Product Operations and am not a Product Manager. If it's too much work to create an internal user how about gifting everyone who uses these integrations a free license to allow them to setup a dedicated integration user?

  • George Smyth
    Reply
    |
    Jan 23, 2024

    Having an Integration user type/role that does not use up one of the user licenses seems very sensible.

    Even a lower cost Aha role that could only do integrations or use the API, but not login and use Aha interactively. At the moment though there are several types of Roles they are priced either full/everything or free. Nothing in between.

  • Christian N
    Reply
    |
    Dec 7, 2023

    Found this while trying to research best practices for Aha <> Jira integrations. Am assuming that b/c the Aha team has left this issue open for 6+ years that there is no material intention to address it.

    If the product architecture is constrained to where this is not possible please at least update your product documentation to indicate that this will either require a separate paid seat or that all automated updates will appear to come from an individual (which may require API key resets if that individual leaves the organization).

  • Cade L
    Reply
    |
    Sep 25, 2023

    This is something we need fixed asap.

  • Guest
    Reply
    |
    Jun 6, 2023

    It would be great for us to have the ability to have an integration user that isn't a paid seat. If we have someone leave or go to a new role, it creates an extra step for us to be able to move the users info

  • Guest
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    Oct 23, 2018

    Agree. SFDC has this ability.

  • Guest
    Reply
    |
    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
    Reply
    |
    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.

     

  • +53
3 MERGED

System account for API access

Merged
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 over 3 years ago in Integrations 0 Future consideration
10 MERGED

Using a single user for integrations

Merged
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 almost 7 years ago in Integrations 0 Future consideration
88 MERGED

Run As User JIRA Webhook Integration Account should not consume a license seat

Merged
https://support.aha.io/hc/en-us/articles/115005972743?input_string=jira+webhook+run+as+user+is+defaulting+to+me%2C+and+it+looks+like+i%27m+synchronizing+all+work+to+jira tells us that if we don't want all imported changes from JIRA to Aha to appea...
Guest about 6 years ago in Jira 17 Future consideration