RELATED IDEAS
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.
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...
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...
0
Future consideration
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.