Hello! We are looking for alternatives to the CCC Last Comment add on that we've lost when we migrated from Data Center to Cloud.
We thought about creating a custom field that would house this data, and populating via a simple automation. However, given the size of our instance and the number of issue updates made daily (approximately 3,900), we could potentially run into throttling or rate limiting issues relatively quickly.
The only marketplace application that I found that may suffice would be last comment field for JIRA (https://marketplace.atlassian.com/apps/2499259263/last-comment-field-for-jira?hosting=cloud&tab=overview ) - but that comes at a cost of approx. $25K for our instance, and does not provide RestAPIs.
Has anyone else come up with a solution for this that they would be willing to share? TIA.
Community moderators have prevented the ability to post new answers.
For this is going to be either an automation (hopefully you are on premium) or a 3rd party app like JMWE or scriptrunner (so you can do more than copying the comment. not like the other app)
Regards, Aaron
Thanks Aaron for the quick response! We are on Enterprise and own both of those add ons. I was hoping not to implement at the workflow due to the potential admin overhead.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Then the safest its the automation. no cap for Enterprise.
Scriptrunner or JMWE post function will be lost in time if you dont have a clear documentation on everything that runs in a workflow.
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Aaron Pavez _ServiceRocket_ I'll review with my stakeholders but I think we'll try the soft launch approach to monitor in Production before socializing it to the masses.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree that automation seems like the safest approach here, especially at this scale.
Since you're handling around 3,900 updates daily, keeping the solution simple should help avoid unnecessary workflow overhead. A custom field populated by automation could also be easier to maintain than relying on a complex post function. It would be worth testing the automation with your actual issue volume before rolling it out broadly. Documentation and monitoring would also make the solution much easier to manage long term.
For local service businesses, having a reliable Seattle installation process can also help maintain consistent customer experiences. Clear workflows and regular quality checks are especially useful when managing installation projects at scale.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm fairly sure that $25K is a pricing mistake on the listing, not the intended price.
I'd email the vendor and ask them to correct it — and while you're at it, ask how the app performs at your scale.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Habib__Plugio__ ,
It does not seem to be pricing mistake. I checked the price for other apps from same vendor. The cost for each app listed is $25000 annually for 10,000 users.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Rilwan Ahmed ,
I mean it is not a well thought pricing policy, is it? It seems they just copy/pasted $0.25 for each bucket.
Of course this is my assumption, because of that I suggested to reach the vendor for confirmation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.