🔀

Workflows

What is a workflow?

A workflow is a system containing a set of interdependent events, components, and actions configured in a permutation to apply to a specific organizational use case at a specific point in time alongside metadata that informs configuration.

Which workflows are available?

Allma provides the user with a technical incident workflow out of the box that may be configured to the team’s satisfaction.

View the 🛠️ Technical incident workflow’s default configuration

Roles

Incident commander

The primary decision maker for the incident, listening to hypotheses and data presented by participants and delegating actions.

Communications lead

The core communicator for the incident, conveying status, updates, and technical details to stakeholders, support personnel, and/or customers.

Participant

Team member available to investigate, carry-out actions delegated by the Incident Commander, and actively work towards incident mitigation.

Watcher

Team member with knowledge or guidance that might contribute to resolution, but is not available to actively investigate or carry-out mitigative actions.

Severity levels

SEV-0

Severe service outage. Service functionality considered down for all or large portions of customers.

SEV-1

Service outage or degradation that impacts customers.

SEV-2

Service or tool outage or degradation that impacts employees, vendors, partners, or other internal stakeholders.

SEV-3

Service or tool outage that has minimal or no impact but requires a response.

Beyond the customizable technical incident workflow, Allma also provides a number of curated workflows which cannot be customized at this time. Workflows can be accessed via /allma new in Slack.

View the 🎡 Sandbox workflow

Basics

  • Description: Easily play around with Allma in a safe space with your team.
  • Channel prefix: sandbox
  • Privacy: public

Roles

Incident commander

The primary decision maker for the incident, listening to hypotheses and data presented by participants and delegating actions.

Communications lead

The core communicator for the incident, conveying status, updates, and technical details to stakeholders, support personnel, and/or customers.

Participant

Team member available to investigate, carry-out actions delegated by the Incident Commander, and actively work towards incident mitigation.

Watcher

Team member with knowledge or guidance that might contribute to resolution, but is not available to actively investigate or carry-out mitigative actions.

Severity levels

SEV-0

Severe service outage. Service functionality considered down for all or large portions of customers.

SEV-1

Service outage or degradation that impacts customers.

SEV-2

Service or tool outage or degradation that impacts employees, vendors, partners, or other internal stakeholders.

SEV-3

Service or tool outage that has minimal or no impact but requires a response.

Other settings

View the 🎲 Tabletop workflow

Basics

  • Description: Refresh your organization on your incident management program or onboard new engineers.
  • Channel prefix: tabletop
  • Privacy: public

Roles

Tabletop manager

The primary organizer and gamemaster for the tabletop exercise, presenting data and context to simulate a real-life incident without interfering with the flow of the incident, and ensuring that participants stay focused and within the scope of the exercise.

Incident commander

The primary decision maker for the incident, listening to hypotheses and data presented by participants and delegating actions.

Communications lead

The core communicator for the incident, conveying status, updates, and technical details to stakeholders, support personnel, and/or customers.

Participant

Team member available to investigate, carry-out actions delegated by the Incident Commander, and actively work towards incident mitigation.

Watcher

Team member with knowledge or guidance that might contribute to resolution, but is not available to actively investigate or carry-out mitigative actions.

Severity levels

SEV-0

Severe service outage. Service functionality considered down for all or large portions of customers.

SEV-1

Service outage or degradation that impacts customers.

SEV-2

Service or tool outage or degradation that impacts employees, vendors, partners, or other internal stakeholders.

SEV-3

Service or tool outage that has minimal or no impact but requires a response.

View the 🔒 Security incident workflow

Basics

  • Description: Start a private channel to run your security investigations.
  • Channel prefix: investigation
  • Privacy: private

Roles

Incident commander

The primary decision maker for the investigation, listening to hypotheses and data presented by participants, delegating actions, and, as needed, communicating progress to senior executives.

Communications liaison

The core communicator for the investigation, conveying status, updates, and details to teams outside of the investigation that may be impacted.

Deputy

Security personnel working on the investigation, carrying out actions delegated by the Incident Commander, and actively working towards remediation.

Subject matter experts

Team members with knowledge or guidance that might contribute to resolution (i.e. Legal, Compliance, CISO, Engineering Leaders).

Severity levels

SEV-0

Critical threat may have been detected, impacting mission critical endpoints. Requires immediate investigation.

SEV-1

Major threat may have been detected, impacting a few top priority endpoints. Requires immediate investigation.

SEV-2

A threat may have been detected, impacting a few endpoints. Requires further investigation during business hours.

SEV-3

A minor threat may have been detected, impacting a few non-mission critical endpoints. Further investigation should be performed during business hours.

View the ❗ Customer escalation workflow

Basics

  • Description: Bring your organization together for troubleshooting customer reported bugs or a customer escalation.
  • Channel prefix: sandbox
  • Privacy: public

Roles

Incident commander

The primary decision maker for the bug report or escalation, listening to hypotheses and data presented by participants and delegating actions.

Communications liaison

The core communicator between internal teams, conveying consumable status and updates for technical and non-technical teams.

Customer facing lead

The bridge between your company and the customer, preparing and distributing external facing status updates.

Technical participant

Team member available to troubleshoot, carry-out actions delegated by the Incident Commander, and actively work towards a solution

Watcher

Team member with knowledge or guidance that might contribute to resolution, but is not available to actively investigate or carry-out mitigative actions.

Severity levels

High

Critical mass of tickets reported by customers with the same symptoms, or a business critical customer(s) is experiencing service degradation. Requires all hands on deck until issue(s) is resolved or has concrete next steps.

Medium

Multiple tickets reporting the same symptoms or an escalated customer(s) experiencing service degradation. Requires quicker turnaround time on issues and next steps.

Low

Several tickets reporting the same symptoms or internally observed service degradation impacting a subset of customers. Requires a proactive approach to address issues.

View the 🐛 Bug bash workflow

Basics

  • Description: Collaborate to discover bugs before they make it to production
  • Channel prefix: bugbash
  • Privacy: public

Roles

Bug bash commander

Primary decision maker + delegator

Engineering lead

Holds technical knowledge. Collaborates with Bug Bash Commander to identify + record bugs

Participant

Stress test feature(s). Identify + record bugs. Provide relevant artifacts (screenshot, link…)

Severity levels

Major Change

Net new functionality, might break old functionality

Change

Material evolution of existing feature(s)

Minor Change

Enhancement or alteration to existing feature

View the 🎥 Sprint project workflow

Basics

  • Description: Collaborate and run a sprint project
  • Channel prefix: sprint-proj
  • Privacy: public

Roles

Sprint project commander

Responsible for delivering the project on time

Engineering lead

Technical expert for the project

Product manager

Product expert for the project

Participant

Contributor to the project

Watcher

Project observer

Severity levels

Major Change

Net new functionality, might break old functionality

Change

Material evolution of existing feature(s)

Minor Change

Enhancement or alteration to existing feature

View the 🚀 Release workflow

Basics

  • Description: Coordinate across stakeholders while running a release
  • Channel prefix: release
  • Privacy: public

Roles

Release commander

Leads team through release

Engineering lead

Technical expert for release

Communications liaison

Keeps stakeholders infromed throughout release

Customer advocate

Keeps customers updated on release

Participant

Helps the release process

Watcher

Observes the release process

Severity levels

Major Change

Net new functionality, might break old functionality

Change

Material evolution of existing feature(s)

Minor Change

Enhancement or alteration to existing features

View the ✨ Release notes workflow

Basics

  • Description: Collaborate on release notes with your team.
  • Channel prefix: release-notes
  • Privacy: public

Roles

Author

Author of the release notes.

Contributor

Potentially helpful individual - engineer, designer, PM, content writer, etc.

Severity levels

Major release

Net new functionality, might break old functionality

Release

Material evolution of existing feature(s)

Minor release

Enhancement or alteration to existing features

View the 🧑‍💻 Code review workflow

Basics

  • Description: Keep stakeholders in the loop while reviewing contributions
  • Channel prefix: code-review
  • Privacy: public

Roles

Reviewer

Code reviewer

Submitter

Engineer submitting code for review

Severity levels

Major Change

Net new functionality, might break old functionality

Change

Material evolution of existing feature(s)

Minor Change

Enhancement or alteration to existing feature

View the 📝 Engineering offboarding workflow

Basics

  • Description: Run offboarding across your Engineering team. Ensure employees have a positive experience
  • Channel prefix: offboarding
  • Privacy: private

Roles

HR

Responsible for overall process + updating people systems, org chart, exit interview

Manager

Ensure offboarding communicated to team and knowledge transfer occurs

Security

Monitor systems, creation of audit trail as needed

IT

Ensure employee removed from systems and company assets recovered

Legal / compliance

Responsible for any legal / compliance issues that arise and execution of legal agreements

Participant

Support offboarding efforts

Severity levels

High risk

Employee leaving in bad faith or highly sensitive situation

Medium risk

Employee leaving on negative terms, sensitive or messy situation

Low risk

Employee leaving in good faith or straightforward situation
View the ➕ Engineering onboarding workflow

Basics

  • Description: Run onboarding across your Engineering team. Ensure new employees are set up with the knowledge, systems, and hardware and continue to learn about the organization and the organization continues to learn about new employees.
  • Channel prefix: eng-onboarding
  • Privacy: private

Roles

HR

Responsible for design and completion of onboarding

Engineering manager

New hire manager

Security

Security expert for onboarding new hire

IT

Technology & hardware expert for onboarding new hire

Legal / compliance

Legal / compliance expert(s) for onboarding new hire

Participant

Additional support for onboarding efforts

Severity levels

Expedited onboarding

A new hire that is breaking onboarding SLAs for critical business reasons. Requires onboarding in expedited fashion with <2 weeks notice before start date

Standard onboarding

A forecasted, planned hire with ample (>2 weeks) notice to start date or within onboarding specific SLAs

Extended onboarding

A forecasted, planned hire with extended (>3 months) notice to start date. Used often for college or entry level hires made far in advanced of planned start dates. May require extra touch points and planning to ensure smooth onboarding
View the ☸️ System migration workflow

Basics

  • Description: Derived from Kelsey Hightower's recommendations for migrating legacy applications to Kubernetes.
  • Channel prefix: system-migration
  • Privacy: public

Roles

Project manager

Responsible for deliverables of the migration, signs off on completion

Application developer

Developers work to ensure the system is behaving correctly, and develop any additional software or tools to ensure a smooth migration

Operations

Operations / DevOps will work with developers to ensure the system is running

SRE

Works to ensure that the application SLI and SLO are being tracked properly and operating within the error budget

Network

Responsible for any network related work that needs to be done

Security

Performs security testing and checks as necessary

Customer facing lead

Works with customers (external or internal) on application availability and communicates maintenance and cutover

Severity levels

Critical

The system being migrated is a critical component to the organization.

Urgent

The system is being migrated due to an urgent need, e.g. failing hardware.

Important

Migration of the system is important to save money or have a consistent deployment plan.

Unknown

The impact of moving the application is unknown.

Favorite workflows

Mark the workflows your team uses with the by adding them to your favorites. Favorite workflows will always appear when kicking off a workflow (i.e. /allma new).

Learn more:

Favorite workflows

How do I kick off a workflow?

via
🤖
Slash commands
:

  • /allma new [instance name] — Declare a new workflow instance and create a channel. (Optional) Any text, including spaces, after new will be used as the incident name.
image

via
🧵
Alert thread actions
:

Allma will offer quick actions in response to other Slack apps within your workspace.

Quick actions will appear in threads when those apps send messages to your Slack if Allma is also present in that channel.

Example:

image

via Allma’s “app home”

  • Navigate to the “Allma” app in your Slack sidebar, then choose New workflow instance
  • image

via Slack’s search:

  • Search Slack (CTRL/CMD K) for Declare new incident
  • image

via Slack’s shortcuts button

  • Search for Declare new incident in the “+” menu, found below where you type messages
Click this “+” icon
Click this “+” icon
Search for “Declare new incident with Allma”
Search for “Declare new incident with Allma”