Inconsistencies between Jira and Confluence Automation

[Koloman Pfeffer]

Hello everyone, 

right now there is a lot of inconsistencies between Jira and Confluence Automation. I get that automations were added to Confluence way later, but now they're here for quite some time and I don't feel that there is any movement in that regard.

If you are used to manage automation flows in Jira, it gets really frustrating by some limitations in Confluence: 

• No dedicated automation user. All automations are executed by their owner which can lead to confused users ("Why did you edit my page here?" - " I didn't, it was an automation.") and problems for version controlled/audited content.
• You can't easily change a flow actor, nor set it to the person who triggered a rule.
• Less dynamic flows by fewer available smart values and lacking CQL documentation.
• Very few automation actions for Confluence in Jira (no feature parity between the two) means that for automating actions between these two Atlassian tools, Webhooks are often necessary, making flows increasingly complicated to maintain.
• Automation documentation generally is often just written with only Jira in mind, glossing over differences in Confluence Automation.

It would be great if some of these things could be resolved in some time and I know there already are support/suggestion tickets for these issues. In general it feels to me like a "fix, improve and refine what's already there before adding more features that feel incomplete".

As it is now, Jira automations offer a lot of flexibility and feel like an actual admin tool to guide users and enforce company policies. Confluence automations comparably feel like a user focused tool, that tries to avoid too much complexity and rather takes users by their hands.

Is this something other users also feel like? Or are my gripes too harsh? Maybe there is a comment by Atlassian about these issues?

[Dan Breyen]

Hi @Koloman Pfeffer as you mentioned, I found a few of these suggestions have been submitted to Atlassian already.

Feel free to vote for and watch them for updates

CONFCLOUD-76428  - "Automation for Confluence" service user

CONFCLOUD-77873  - Smart Values for Confluence Automation

There were several others submitted around actions. If you see them out on Atlassian's Jira Site, I would suggest mentioning them here so they can get some more votes.  

More votes always helps.

I added a vote for these as well as the ones suggested by @Viswanathan Ramachandran 

[Viswanathan Ramachandran]

Hi @Koloman Pfeffer 

Spot on. You're right and you spoke other Confluence SME's mind. 

See these :

https://jira.atlassian.com/browse/CONFCLOUD-81227

https://jira.atlassian.com/browse/CONFCLOUD-76428

https://jira.atlassian.com/browse/CONFCLOUD-80002

Hope we all get this answered soon.

My personal opinion:

I love Confluence, it's a imperfect twin of Jira. I prefer Atlassian needs to focus on a unified 'Atlassian Automation' engine rather having the feature on different toolsets. 

Workarounds?
Until Atlassian delivers true feature, let's use Confluence as the frontend display and Jira as the backend engine using these heavy options:

1. The Paid Bot Account: Many enterprise teams burn a paid user license solely to create an account called "Confluence Bot". They log in as the bot to build/own the rules so that page histories are audited cleanly.
2. Orchestrating via Jira Automation+API: Instead of relying on Confluence smart values, run the rule in Jira (system account) and use Jira's Send Web Request action to hit the Confluence v2 REST API to update, create, or modify Confluence pages.