Dedicated Integration User

I'd even love the ability to specify the integration user (the "Run as Me" option) directly from the integration settings vs the only option being myself. That means I have to log in as the user, navigate to the settings, and then select "Run as me" which is a cumbersome process.

Facing this while implementing gitlab integration -- everything looks like it is created and updated by me.

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.

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?

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.

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

This is something we need fixed asap.

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

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.

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.

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

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.

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

Agree. SFDC has this ability.

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.

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.