Introduction to Automations

[#1]

Go Go Automations! (Sing this in your head to the 1990's Power Rangers theme and you'll get where I"m going :D)

Automations allow users to setup a series of steps a system should follow to take some action for them. This makes them especially useful for administrative actions (keeping track of pages to archive, missing page owners etc) that take up a lot of manual time.

Figuring out what to automate can be challenging. For me there's two parts we need to understand. Typically folks run into trouble when they don't understand either side of this equation (or both!):

1. Determining what you want to automate
2. Understanding what your system can do

For example, if I don't know what Confluence can automate I might not even both looking into this. Alternatively if I know what it can do, but don't have anything it should automate the feature is just as useless.

Finding things to automate can be the easier part of this - just go talk to people. Ask them what they do in Confluence all day, or what frustrates them, or what takes a lot of time. Get a list going, and then after a while review them. This will give you a good idea of where you can provide a lot of value with automations.

Fortunately solving #2 is as simple as getting hands on. Get into Confluence and start looking at automations. There's a load of templates you can tinker with (and if you've got Premium or Enterprise Atlassian Intelligence will create them for you based on natural language prompts).

Use cases

There's a few stereotypical use cases for automations (and by no means is this a complete, exhaustive, list).

1. Finding pages to archive - An automation can run on a regular basis and auto-archive older content. Great for keeping your content hierarchy in shape.
2. Finding pages with inactive owners - Orgs will eventually run into an issue where pages don't have active owners. This is insanely hard to keep track of manually, but you can automate the problem away by tagging pages without owners for followup.
3. Create Jira tickets - One use case I find useful is automatically creating Jira tickets based on some criteria. This helps create sprints, build retro tickets and more.

Parts

Every automation must have two parts - a trigger and an action.

Triggers are what tell Confluence to run the automation. Triggers include things like scheduled, manual, when a page is moved or edited and more.

Actions are what the automation does. Examples include things like create a page, move something, add a comment and more. 

Additionally automations can have two other parts, conditions and branches.

Conditions let you control the flow of the automation. For example you might only want it to continue if a page has a specific word in it's title, or if it was created by a certain person. Conditions also allow for if/then logic, providing the ability for the automation to take different action based on information within the page.

Branches allow the automation to repeat actions for related items. Most commonly I use this for child pages (e.g. run this part of the automation against every child page of the parent).

Limitations

In Cloud there are limits to how many automations you can run. In my mind this makes sense as smaller groups would have less to automate, but it can still put groups on Standard in a bit of a bind if they have legitimate need for more runs.

1. Free - 10 runs per instance per month
2. Standard - 100 runs per instance per month
3. Premium - 1000 runs per user per month
4. Enterprise - Unlimited

Final thoughts

Check out a youtube video of this here:

[Barbara Szczesniak]

@Robert Hean This turned into a rather long-winded set of questions, so let me know if I should just ask it all in the automation channel.

Thanks for this clear overview. So far, I have fallen into the I don't have anything to automate camp, since I'm basically using Confluence to document our application for internal users. Plus, we have Confluence Standard, so I don't want to use up our execution limit in case someone else is using automations.

We do, however, have Jira Premium. Does that give us more runs per month if we start the automation from Jira to affect something in Confluence?

We are starting an initiative to have better functional documentation in addition to the user documentation I create. (It would also help me with the user docs to have fuller design/functional documentation, since the tickets never quite explain everything or capture changes made during implementation.)

I'm thinking that we might:

• generate pages in Confluence based on one or more old Jira tickets to document existing functionality, and then someone from the team can go in and flesh out the Confluence page with more detail.
  • Am I right that these would count as Jira automations?
  • Can we add content in a single Confluence page from multiple tickets?

and then either:

1. write up pages in Confluence describing the design/requirements/etc. for a new feature/epic and then do a Confluence automation to generate Jira tickets, which someone would probably need to go through and add detail on.
   • Can the automation create an epic ticket and child tickets, or would it just create the epic and we need to create the child tickets manually in Jira?
   • Can we run 1 automation execution against multiple Confluence pages to generate tickets for all of them keep our runs down?
2. write new epic/child tickets in Jira for new features and then generate Confluence pages from those like described above for the old tickets

I'm leaning toward #1, since I think it's better to think it all out in Confluence before generating the tickets, but then we might have to worry about the 100 runs limit.

Additional question: If we later make modifications to the functionality described on the Confluence pages: 

• if the related Jira tickets are still open, do we need to manually update them?
• if the changes require new tickets, can we run an automation in Confluence to generate new tickets based on just the changes?
• would we need an automation that uses Rovo to generate new or update the appropriate items?

[Robert Hean]

Heya @Barbara Szczesniak  - thanks for responding and love the questions! Responses below...

A loom video:

<iframe src="https://www.loom.com/embed/b46e7da52fdf4b97a49399f5207c5bfc?sid=df2818cd-a57c-4e32-9e01-2d549bd18238" frameborder="0" allowfullscreen="allowfullscreen" webkitallowfullscreen="webkitallowfullscreen" mozallowfullscreen="mozallowfullscreen" style="height: 100%; width: 100%;"></iframe>

---

We do, however, have Jira Premium. Does that give us more runs per month if we start the automation from Jira to affect something in Confluence?

• As I understand it the automation is counted in the system it is triggered in. There is, however, limited actions you can take in Confluence from within JSM (currently just "Edit a page" and "Create a page".  Note that the first one will ONLY append info to a page).

---

For this scenario:

Generate pages in Confluence based on one or more old Jira tickets to document existing functionality, and then someone from the team can go in and flesh out the Confluence page with more detail.

Am I right that these would count as Jira automations?

• As long as the automation is triggered in Jira it should.
• You could easily have a trigger be "when work item closed create a page with XYZ info from the work item"

Can we add content in a single Confluence page from multiple tickets?

• Sure - just note that the automation can currently on append info to the END of a page (e.g. it can't insert it in the middle) so you'd likely have to manually review/adjust.

---

For this scenario:

#1 Write up pages in Confluence describing the design/requirements/etc. for a new feature/epic and then do a Confluence automation to generate Jira tickets, which someone would probably need to go through and add detail on.

#2 write new epic/child tickets in Jira for new features and then generate Confluence pages from those like described above for the old tickets

Can the automation create an epic ticket and child tickets, or would it just create the epic and we need to create the child tickets manually in Jira?

• You can generate multiple child tickets to a parent via automation

Can we run 1 automation execution against multiple Confluence pages to generate tickets for all of them keep our runs down?

• This feels like more of a Rovo ask - e.g. "read all the pages with X label" or "read all the pages from the past X days" and then "generate jira work items.
• One thing to keep in mind is that automations don't understand the content they run against - they just follow rules - so having it analyze a page and make decisions may not work (hence the Rovo idea).

My thoughts - You're likely better creating the Confluence content FIRST since that may line up with planning better (and have it all in one spot) then using Rovo and/or Automations to slice it up.

---

For this scenario

Additional question: If we later make modifications to the functionality described on the Confluence pages: 

if the related Jira tickets are still open, do we need to manually update them?

• The tickets won't auto-update to match the Confluence page
• I'd suggest putting a hyperlink on the Confluence page to the work item and linking the work item to the page, this way you can easily go between them to adjust as needed

if the changes require new tickets, can we run an automation in Confluence to generate new tickets based on just the changes?

• Not with Rovo (automations don't "read" a page like people, but Rovo could potentially grab new updates and work on those).

would we need an automation that uses Rovo to generate new or update the appropriate items?

• Likely!