Customising work item types in Almo means controlling the list of Azure DevOps types you see in the add-in, and the order they appear in. Almo arrives with the most common Azure DevOps types ready to go, so most teams can start without changing anything. You customise the list for two reasons: your organisation uses bespoke work item types that Almo does not show out of the box, or you want a shorter, focused list of only the types you actually work with. This guide covers what work item types are, where to customise them, how to add bespoke types, and how to reorder or remove the ones Almo shows.
What are work item types in Almo?
Work item types are the categories Azure DevOps uses for the things a team tracks, such as Feature, Bug, Task, and Issue. In Almo, the Supported Work Items list controls which of these appear when you create or open a work item. You decide which types Almo shows, and the order they appear in, from the Customise Work Item Types screen.
The types Almo shows by default
Almo comes pre-configured with the most common Azure DevOps types: Feature, Task, Bug, Product Backlog Item, and Issue. These match the standard Azure DevOps process templates, so most teams can start straight away. The list is worth changing when your projects use custom types, or when some of the defaults are not relevant to how you work.
How to customise work item types in Almo
Open the Supported Work Items setting. In the Almo pane, open Settings. In the Work Item card, select the Customise link next to Supported Work Items.
Review what Almo already shows. The Customise Work Item Types screen opens with a Supported Work Items section at the top, listing the types Almo currently displays with a tick beside each.
Add types from All Work Items. Below it, the All Work Items section lists every work item type your connected Azure DevOps projects define, including any custom types your team has added. Tick the ones you want Almo to show. To find a type quickly, type its name into the search field at the top.
Set the order, then save. Use Reorder to arrange the types, clear the tick on any you do not need, and select Save.
Customising work item types in Almo. In Settings (left), the Work Item card has a Customise link next to Supported Work Items. The Customise Work Item Types screen (right) shows the enabled types under Supported Work Items, with every other type from your connected projects, including custom ones, listed under All Work Items. Tick a type to add it, clear a tick to remove it, then save.
Adding a custom work item type
Any work item type defined in your connected Azure DevOps projects appears under All Work Items, including custom types your team has created. Tick the type to move it into Supported Work Items, then save. If a custom type is not in the list, the project that defines it is most likely not connected yet; connect that organisation first, then reopen the screen.
Reordering the list
The order of types under Supported Work Items is the order they appear when you create or change a work item in Almo. Select Reorder to move the types you use most to the top, so they are the first options you reach for, then save to apply the new order.
Removing a type you do not use
To take a type off the menu, clear its tick under Supported Work Items and save. This only changes what Almo shows you. The work item type, and any items already created with it, stay in Azure DevOps.
When your changes take effect
Your selection applies as soon as you save, and Almo’s create and edit menus show the updated list right away. Because Almo settings roam across the devices where you use it, the same list follows you between Windows, Mac, and Outlook on the web. You can return to the Customise Work Item Types screen whenever your process changes.
Why is a work item type missing from the All Work Items list? A type appears only if one of your connected Azure DevOps projects defines it. If a custom type lives in a project you have not connected, connect that organisation first, then reopen the screen.
Can I add custom work item types my team created in Azure DevOps? Yes. Any custom type defined in your connected projects shows under All Work Items. Tick it and save, and it appears in Almo alongside the standard types.
Will removing a type delete its work items? No. Clearing a type from Supported Work Items only hides it from Almo’s menus. The type, and every work item created with it, stay in Azure DevOps.
Do my work item type settings apply on my other devices? Yes. Almo settings roam with your account, so the types you enable follow you across Windows, Mac, and Outlook on the web.
How do I change the order the types appear in? Open the Customise Work Item Types screen, select Reorder, arrange the types, and save. The order you set is the order Almo shows them in.
Almo, set to your team’s process
Setting Almo’s work item types to match your Azure DevOps process means the menus you use every day show the types your team works with, and nothing it does not. The screen takes a moment to set up, and you can return to it whenever your process changes.
If anything on this screen does not behave as described here, the Almo team can help. Write to [email protected] or raise a support ticket from inside Almo.
How to find Azure DevOps work items from Outlook with Almo Discover
Almo’s Discover feature lets you find any Azure DevOps work item from Outlook and act on it without switching to a browser. When an email mentions a work item, you search for it from the Almo pane, open it, and update it in place. This guide covers how to open Discover, how to search, what the results tell you, and how to change the project you are searching.
If you have not connected Almo to Azure DevOps yet, start with Connect Almo to Azure DevOps and come back once your Working Project is set.
What the Discover feature is
Discover is Almo‘s search tool for existing Azure DevOps work items, built into the Outlook pane. It searches the project you are working in by phrase, work item ID, or title, and returns matching items with their status, assignee, and last activity. You open any result and update it without leaving Outlook.
Without it, replying to an email about a work item means switching to the Azure DevOps portal, searching there, and bringing the details back. Discover removes that round trip, because the search happens next to the email you are answering.
How to find a work item with Discover
Open Discover from the Almo home screen. On the Almo home screen, select Discover. The search screen opens, set to your current Working Project.
Check or change the project you are searching. Discover searches one project at a time, starting with your Working Project, which is shown at the top of the screen. To search a different one, select Change and pick another connected project.
Enter your search and select Search. Type a search phrase, a work item ID, or part of a title into the search field, then select Search. Select Clear to start a new search.
Open a result and act on it. Select any result to open the work item. From there you can add a comment, update fields, change its state, or link it to the email you are reading.
Discover in three steps. From the Almo home screen (left), select Discover to open the search screen (centre), which starts on your Working Project with a Change link to switch. Enter a phrase, ID, or title and select Search to see matching work items (right), each with its ID, title, project, assignee, status, and last activity.
What the search results show
Each result gives you enough context to pick the right work item before you open it:
Detail
What it tells you
Work item ID
The Azure DevOps ID for the item, for example #56.
Title
The work item’s title, so you can confirm it is the one you mean.
Project
The connected project the item belongs to.
Assignee
Who the item is currently assigned to.
State
The item’s current status, such as Committed or Active.
Last activity
How recently the item was updated, for example 24 minutes ago.
Searching a different project
Discover starts on your Working Project because that is the project holding most of your day-to-day work items. When the item you need belongs to another project, select Change at the top of the Discover screen and choose any project you have connected. Discover then searches that project instead.
Because Discover searches one project at a time, the quickest way to work across several is to set the project you use most as your Working Project and use Change for the occasional search elsewhere. Change your Working Project in Almo explains how to switch your default.
Acting on a work item from your results
Opening a result puts you in the same work item form you use to create items, so anything you can do to a new work item you can do here. Add a comment, reassign it, change its state, edit fields, or link it to the email you are reading so the conversation and the work item stay connected. Overview of the Almo work item form covers the form in full.
Tips for faster searches
A few habits make Discover quicker day to day. Searching by work item ID is the most precise route when you have the number from an email or a notification. A short, distinctive phrase from the title narrows results faster than a common word that appears in many items. And keeping your Working Project set to the project you are actively working in means most searches need no project switch at all.
Troubleshooting Discover
Why are no results showing for my search?Discover only searches the project shown at the top of the screen. If that is the wrong project, select Change and pick the right one. If the project is correct, try a shorter or more distinctive phrase, or search by the work item ID.
Can I search every project at once? No. Discover searches one connected project at a time, starting with your Working Project. To look in another project, use the Change link to switch, then search again.
Why is a work item I expected missing from the results? It is most likely in a different project from the one you are searching, or your search phrase does not match its title. Switch projects with Change, or search by its work item ID to find it directly.
Can I update a work item from Discover, or only view it? You can update it. Selecting a result opens the full work item form, where you can comment, reassign, change its state, edit fields, and link the item to your current email.
How is Discover different from the Recently updated list on the home screen? Recently updated shows items in your Working Project that changed lately, without you searching. Discover is for finding a specific item on demand, by phrase, ID, or title, including in projects other than your Working Project.
Every work item, one search away
Discover keeps every Azure DevOps work item one search away from the email in front of you. Rather than switching to the portal to look something up, you search, open, and update from the same pane you are already working in.
If a search does not behave as described here, the Almo team can help. Write to [email protected] or raise a support ticket from inside Almo.
Your Working Project is the Azure DevOps project Almo treats as home, and you can change it in a few seconds from Almo’s settings. When you move to a different team or your sprint shifts to another project, you point Almo at the new one and its home screen updates straight away. This guide covers what the Working Project controls, when to change it, how to switch in a few steps, and how to switch back.
If you have not connected Almo to Azure DevOps yet, start with Connect Almo to Azure DevOps, where you set your first Working Project, then come back here when you need to switch it.
What is a Working Project in Almo?
A Working Project is the single Azure DevOps project the Almo Outlook add-in focuses on by default. The work items on your Almo home screen (linked, related, and recently updated) all come from it. You set one Working Project when you first connect, and you can switch to another from Almo’s settings at any time.
When to change your Working Project
You set one Working Project at a time because it keeps Almo’s home screen focused on the work in front of you. Change it whenever that focus moves: your sprint shifts to a different project, you join or cover for another team, or a support rotation spans more than one project. Switching takes a few seconds, so there is no cost to moving your focus as often as your work does.
How to change your Working Project in Almo
Open Settings in Almo. In the Almo pane, select the settings (gear) icon at the top.
Select Modify next to your Working Project. The Settings screen shows your current Working Project at the top, for example Project 3 (almo.net). Select the Modify link beside it.
Choose a project from the list. The Modify Working Project screen lists every connected server (each one an Azure DevOps organisation) with its projects beneath it. Your current Working Project carries a Working Project badge. Select the radio button next to the project you want.
Save your choice. Save the change using the Save control below the project list. Almo immediately starts showing recent activity from the new project.
Changing your Working Project in Almo. In Settings (left), select Modify beside your current Working Project. The Modify Working Project screen (right) groups your projects under each connected server (an Azure DevOps organisation), with the current one marked by a Working Project badge. Select another project and save.
What changes after you switch
As soon as you save, your Almo home screen reflects the new project. The recently updated work items and suggestions now come from it. Existing links between emails and work items are untouched, because changing your Working Project changes what Almo shows by default, not the work items themselves.
How to switch back
Switching back uses the same screen. Open Settings, select Modify beside the Working Project, choose your previous project, and save. There is no limit on how often you switch, so you can move your focus as your work moves.
The Modify Working Project screen is also where you manage the servers you have connected. From here you can add another Azure DevOps organisation, including one you reach through a Personal Access Token, or remove a server you no longer use. Connect Almo to Azure DevOps covers adding a server in full.
Working across more than one project
You set one Working Project at a time, but you are not limited to it. Discover, Almo’s search for existing work items, can look inside any connected project without changing your default. The practical approach is to keep your Working Project set to where most of your day-to-day work sits, and reach for Discover when you need an item that lives elsewhere. Find work items from Outlook with Almo Discover covers it in full.
Troubleshooting your Working Project
Where do I change my Working Project in Almo? Open Settings in the Almo pane, then select Modify next to the Working Project shown at the top. Choose a project from the list and save.
Will changing my Working Project affect work items already linked to my emails? No. Changing your Working Project changes the project Almo focuses on by default. Existing links between emails and work items stay in place.
Does my Working Project stay the same on my other devices? Yes. Almo settings, including your Working Project, sync across the devices where you use Almo, so your choice follows you between Windows, Mac, and Outlook on the web.
Why is the project I want missing from the list? The Modify Working Project screen only lists servers you have already connected, where each server is an Azure DevOps organisation. If the project belongs to an organisation that is not there, connect it first. For an organisation outside your Microsoft account, add it with a Personal Access Token, which the connection guide walks through.
Can I search a project without making it my Working Project? Yes. Use Discover to search any connected project on demand. Your Working Project stays as your default while you do.
Always focused on the right project
Your Working Project keeps Almo focused on the project you are working in, and changing it takes only a few seconds whenever that focus moves. Set it to where your work sits today, and switch as soon as it moves on.
If anything about switching your Working Project does not behave as described here, the Almo team can help. Write to [email protected] or raise a support ticket from inside Almo.
Connect Almo to Azure DevOps: a complete setup guide
Almo runs inside Outlook and connects it to your Azure DevOps organisation, so you can create, track, and manage work items without switching applications. Before any of that, you connect the two.
There are two ways to do it.
The first is to sign in with the Microsoft account you already use for Outlook, which is the route most people take and is close to automatic.
The second is to connect with a Personal Access Token, a scoped Azure DevOps credential you use in place of a password. You need it only when a Microsoft sign-in cannot reach the organisation you are after. This guide covers both routes, the one-time IT approval some organisations require, and the issues that come up on a first connection.
Before you start
You will connect faster if these are in place:
New Almo installed from Microsoft AppSource and open in Outlook (Windows, Mac, or Outlook on the web – the steps are the same everywhere).
The Microsoft account you use for Outlook, which is usually your work account.
Access to at least one Azure DevOps organisation and project. If you can open work items in the Azure DevOps web portal, you have what you need.
Some organisations also require their IT administrator to approve Almo once before anyone in the organisation can sign in. The IT approval section below covers what to do if that applies to you.
Option 1: Sign in with Microsoft (recommended)
This is the route to take whenever your Azure DevOps organisation sits under the same Microsoft account as your Outlook. It needs no new credentials and no manual server URLs.
Open Almo in Outlook and select Sign in with Microsoft. Almo uses the account you are already signed into Outlook with, so there is nothing new to type.
Let Almo discover your organisations and projects. Once you are signed in, Almo reads the Azure DevOps organisations and projects your account is permissioned on and lists them for you. Classic Almo made you type a server URL by hand; New Almo finds them for you, which is why this step is close to instant.
Choose your Working Project and select Continue. Pick the one project you want Almo to focus on by default. You can change it later at any time.
Set your Working Project in Almo. The connection screen lists each discovered Azure DevOps server with its projects as selectable options, a Continue button, and an Add Server (via PAT) link at the bottom.Almo lists every Azure DevOps server and project your account can reach. Select one project as your Working Project, then select Continue. The Add Server (via PAT) link at the bottom is for the token-based route covered further down.
That is the whole flow. From here you can create, update, link, and track Azure DevOps work items from any email in Outlook.
What a Working Project is, and why you set it now
Your Working Project is the project Almo treats as home. When you open Almo next to an email, the items it surfaces by default – the ones linked to that email, related items from the same thread, and recently updated work items – all come from your Working Project. Setting it during connection means Almo shows you relevant work from the first email you open rather than an empty screen.
You are not locked in. Most people work across more than one project over a sprint, and switching takes a few seconds from Almo’s settings. We cover that in its own guide: Change your Working Project in Almo.
Option 2: Connect with a Personal Access Token (PAT)
A Microsoft sign-in reaches every organisation your account is permissioned on. When the organisation you need sits outside that account, you connect it with a Personal Access Token instead. This covers a few real situations: you are a guest in another company’s tenant, the organisation sits in a separate Microsoft tenant from your Outlook account, you work with a contractor or client organisation, or you keep a personal Azure DevOps organisation under a different login.
A PAT is an Azure DevOps token that acts as an alternative password. It is scoped to specific permissions, you set its expiry, and you can revoke it whenever you want. You create it once in Azure DevOps and paste it into Almo. Microsoft’s own guide, Use personal access tokens, explains what a PAT is and how it works in full.
Where to add a PAT in Almo
You can add a server with a PAT at two points, and both open the same dialog. During your first connection, the Set Working Project screen carries an Add Server (via PAT) link at the bottom. After that, you reach the same place from Settings at any time: select Modify next to your Working Project to open the Modify Working Project screen, which lists every server you have connected and carries the same Add Server (via PAT) link.
That screen is also where you manage your connections. You can add as many servers as you need, edit or remove the ones you already have, and switch your Working Project between any of their projects as often as you like. Change your Working Project in Almo covers the switching side in detail.
Selecting Add Server (via PAT) opens the Add New Server dialog, with two fields: Organization URL and Personal Access Token (PAT).
Adding a server with a PAT in Almo. The Add New Server dialog has an Organization URL field and a Personal Access Token (PAT) field, with Cancel and Connect buttons.Selecting Add Server (via PAT) opens the Add New Server dialog. Paste your organisation URL and your token, then select Connect. Almo validates both before adding the server.
Keep the dialog open, then create the token.
Create the token in Azure DevOps
In the Azure DevOps web portal, open User settings (the gear icon near your avatar) and select Personal access tokens.
Select + New Token.
Give it a recognisable name (for example, Almo Outlook add-in), choose the organisation it applies to, and set an expiry. A shorter expiry is safer; you can always create a new token later.
Under Scopes, choose Custom defined, then enable the three scopes Almo needs.
These three are the minimum for Almo to work correctly:
Work Items – Read, write, & manage. This is the core permission. It lets Almo create, read, update, and delete work items, manage links between them, handle attachments, and add comments.
Project and Team – Read. This lets Almo list your organisations and projects, and read work item types and fields. Without it, the project list comes back empty.
User Profile (vso.profile) – Read. This lets Almo populate the Assigned To list with the people in your organisation. Without it, you cannot assign work items to anyone.
A token missing any of these will appear to connect and then fail the moment Almo tries to read project types or list users, so it is worth setting all three now rather than diagnosing a half-working connection later.
Two more scopes are optional. Add Code – Read if you want to link work items to pull requests, commits, or branches, and Graph – Read for richer user and group search. You do not need Build, Release, Test, Analytics, or any other scope.
When you select Create, Azure DevOps shows the token once. Copy it straight away and keep it somewhere safe, because it is not shown again.
Enter your Organization URL in the form https://dev.azure.com/your-organisation.
Paste your token into the Personal Access Token (PAT) field.
Select Connect. Almo validates the token and its scopes, then adds the organisation to your server list so you can pick a project from it.
Keeping the token safe
A PAT is as sensitive as a password, so treat it that way. Grant only the scopes above, set an expiry rather than letting it run indefinitely, and revoke it from Azure DevOps user settings if you stop using Almo or suspect the token has been exposed. When a token expires, create a fresh one and reconnect.
If your IT team needs to approve Almo first
Organisations that manage app access centrally need an administrator to grant consent once before anyone in the organisation can sign in. After that single approval, every user can connect with the Microsoft sign-in route above, and new team members get access automatically.
If you are the IT administrator, the quickest path is one-step admin consent, where you approve Almo’s Microsoft and Azure DevOps permissions in a single visit. The alternative is to grant the two sets of permissions separately in the Azure and Entra portals. Adding Almo to Entra: a guide for IT admins walks through both, with screenshots.
If you are not the administrator and you hit a Microsoft “Approval required” screen when signing in, request access from that screen directly. Submit it with a short note on why you need Almo, and your administrator approves the request once. Requesting access to Almo shows exactly what that looks like.
Troubleshooting a first connection
Why is my organisation or project list empty after signing in? This almost always means your account is not permissioned on any Azure DevOps organisation that the sign-in can reach, or your IT team has not yet approved Almo. Confirm you can open the project in the Azure DevOps web portal, check the IT approval section above, and use a PAT if the organisation sits under a different account.
Why is a project I expected missing from the list? You are likely connected, but not permissioned on that specific project. Ask the project administrator to add you, then reopen the project list in Almo.
Why won’t my Personal Access Token connect? Check the token in this order: it has not expired, it has all three required scopes (Work Items, Project and Team, and User Profile), the Organization URL is exactly https://dev.azure.com/your-organisation, and your account actually has access to that organisation. A scope gap is the most common cause, so re-check those first.
Why can’t I connect with a guest account? Guest access often will not surface the host organisation through a standard sign-in. Connect that organisation with a PAT instead, following Option 2 above.
Why does sign-in keep looping or show “Approval required”? Your organisation requires admin consent. Submit the access request from the approval screen as described above, and you will be able to sign in once it is granted.
You are connected
Once Almo is connected, the rest follows from your inbox: open an email, see the work items linked to it, and create or update Azure DevOps work items without leaving Outlook. Setting your Working Project during connection means that view is useful from the very first email you open.
If your connection does not behave as described here, the Almo team can help. Write to [email protected] or raise a support ticket from inside Almo.
With the inbuilt Templates capability in Azure DevOps, you can apply a chosen set of default field values every time you create a work item, in a single click. Templates are a native Azure DevOps feature, and New Almo works with them directly, so a template you create in Azure DevOps is available in Almo, and a template you capture in Almo is available to your team in Azure DevOps. What Almo adds on top is the ability to populate those field values from the email a work item came from, which Azure DevOps templates cannot do on their own.
This guide explains what these templates are, how to create and apply one from within Outlook, how to populate fields from an email, and how to import the templates you already built in Classic Almo.
New here? Almo is a Microsoft Outlook add-in for creating, tracking, and managing Azure DevOps work items from your inbox. This guide assumes you have already connected Almo to Azure DevOps.
What is an Azure DevOps work item template?
A work item template holds a chosen set of field values – such as the assignee, tags, state, and an opening description – that Azure DevOps applies to a new work item so your team does not enter the same details by hand each time. Because the template is stored in Azure DevOps rather than on a single machine, everyone on the project can use it, and it appears in the Azure DevOps portal alongside your work items. Each template belongs to one work item type, so a Bug template applies to Bugs and a Task template applies to Tasks.
New Almo uses these native templates as they are, with no separate template library to maintain. A template created in either place is available in both.
What Almo adds: Email Expressions
A standard Azure DevOps template applies fixed values and has no way to read the email a request arrived in. Almo closes that gap. When you build a template in Almo, you can point a field at the email instead of giving it a fixed value, so the work item title can take the email subject, a reporter field can take the sender’s name, and a date field can take the date the email arrived. These placeholders are called Email Expressions, and the full list appears further down.
How to create a work item template in Almo
You create a template by capturing a work item you have already filled in. The Template button sits at the top of any work item you are creating or editing.
The Template button sits at the top of the work item form. Select it to open the menu.
Open the Template menu. On a work item, select Template. The menu opens with Capture at the top, followed by every template already available to you, including any built in the Azure DevOps portal.
Select Capture. The current form, with its field values, tags, and description, opens in the New template screen, which shows the work item type and the server the template belongs to.
Name the template. Enter a Name, and a short Description if your team keeps several.
Set the fields. Use Add new field to choose a field and the value it carries. To populate that value from the email, select the envelope icon beside it and choose an Email Expression.
Add an opening comment if it helps. A triage checklist or a definition of done can sit in the comment editor so that it appears on every work item created from the template.
Save. The template is stored in Azure DevOps and is available in both Almo and the portal.
The New template screen. Select the envelope icon beside any field’s Value to replace a fixed value with an Email Expression – the placeholder Almo fills from the current email when the template is applied.
How to apply a template
To apply a template, open the Template menu on a work item and select its name. Almo populates the form with the template’s values and replaces each Email Expression with the matching detail from the current email. Adjust anything specific to this work item, then save it as usual.
The Template menu lists Capture at the top and every saved template below. Select a template name to apply it to the current work item.
How to edit or remove a template
To change a template, open the Template menu and select the pencil icon beside its name. The editor opens with the fields you set when you created it. Because the template is stored in Azure DevOps, your change applies for everyone who uses it.
Email Expressions Almo supports
In the New template screen, select the envelope icon beside any Value field and choose an expression. Almo replaces it with the real value when the template is applied.
Expression
Replaced with
[BODY]
The body or text of the email.
[TOEMAIL]
The recipient’s email address.
[TONAME]
The recipient’s name.
[FROMEMAIL]
The sender’s email address.
[FROMNAME]
The sender’s name.
[SUBJECT]
The subject of the email.
[SENTDATE]
The date the email was sent.
[RECEIVEDDATE]
The date the email was received.
[NOW]
The current date, from your computer’s calendar.
[ALL-TO-RECIPIENTS]
A semicolon-separated list of Name <Email> for every recipient.
[ALL-CC-RECIPIENTS]
A semicolon-separated list of Name <Email> for every CC recipient.
[ALL-BCC-RECIPIENTS]
A semicolon-separated list of Name <Email> for every BCC recipient.
Setting the title to [SUBJECT] turns a support request into a work item titled with the customer’s own subject line, and adding [FROMNAME] to a field records who raised it, without any manual entry.
How to import your Classic Almo templates
If you used Classic Almo, you do not need to rebuild your templates by hand. New Almo reads your Classic template files and recreates each one as an Azure DevOps template. Classic Almo stored each template as a JSON file under %appdata%\vi8\almo\templates on the machine where it ran, and New Almo imports those files to create the equivalent Azure DevOps template for each one.
In Almo, open Settings and locate the Template Management card.
Select Import Template.
Choose the JSON files from %appdata%\vi8\almo\templates.
Almo creates a matching Azure DevOps template for each file, and they appear in the Template menu alongside the rest. The same card links to a view of every Azure DevOps template you already have, so you can confirm what was imported.
The Template Management card in Settings. Import Template reads your Classic Almo template JSON files from %appdata%\vi8\almo\templates and recreates each one as an Azure DevOps template.
How templates stay in sync with Azure DevOps
Because Almo works on the native templates, nothing has to be exported or kept in two places. A template a colleague creates in the Azure DevOps portal is available in your Template menu the next time you create a work item, and a template you capture in Almo appears in the portal for anyone on the project. Editing a template once updates it for everyone who uses it, and moving to a new machine carries your templates with you, because they were never tied to the old one.
If you are moving from Classic Almo, this is the change worth knowing. Classic Almo kept its own templates as files on each PC, while New Almo stores them in Azure DevOps where your team can see and share them. For how the feature worked before, see Templates: remove manual data entry.
Frequently asked questions
Are Almo templates the same as Azure DevOps work item templates?
Yes. New Almo uses native Azure DevOps work item templates rather than keeping its own, so a template you create in the Azure DevOps portal appears in Almo, and a template you create in Almo appears in the portal.
Do templates I create in Azure DevOps show up in Almo?
Yes, with no import step, because any work item template in your connected Azure DevOps projects is listed in Almo’s Template menu.
What can Almo templates do that Azure DevOps templates cannot?
They can populate fields from the email. A native template applies fixed values only, whereas Almo lets a field take an Email Expression such as [SUBJECT] or [FROMNAME] and fills it from the email when the template is applied.
Can I bring my Classic Almo templates into New Almo?
Yes. Open Settings, locate the Template Management card, select Import Template, and choose your Classic template JSON files from %appdata%\vi8\almo\templates. Almo recreates each one as an Azure DevOps template.
Where did Classic Almo store its templates?
As JSON files under %appdata%\vi8\almo\templates on the PC where Classic Almo ran.
Can my team use the templates I create?
Yes, because they are stored in Azure DevOps, so anyone connected to the project can apply them.
How do I edit or delete a template?
Open the Template menu and select the pencil icon beside its name. Your change applies for everyone, since the template is stored in Azure DevOps.
Almo is a Microsoft AppSource Outlook add-in. Before users in your organisation can sign in, an IT Administrator needs to grant admin consent once, organisation-wide. This consent is granted via Azure Portal and Entra.
This page explains what permissions Almo requires, why, and how to grant them. (new version coming soon)
Security Certification
Almo is listed on Microsoft AppSource, Microsoft’s verified marketplace for Outlook add-ins. Before any add-in is published on AppSource, Microsoft requires it to pass a security and compliance review.
Almo connects Outlook with Azure DevOps. These are separate Microsoft platforms with separate permission models, so Microsoft handles consent for each independently.
Microsoft 365 / Outlook
Almo reads the sender address and thread content of the email it is open next to. This is what allows it to surface relevant Azure DevOps work items alongside the right email.
Azure DevOps
Almo creates, finds, links, and updates work items in the Azure DevOps projects your users connect to.
Each consent screen lists the exact permissions being requested for that system.
Due to Almo working across two Microsoft products, IT Admin consent is required for Almo to be able to connect to both of them. There are two ways to provide this consent. We present both of them below.
Option 1: One-step consent
For most organisations, both grants can be completed using a single link. Clicking it opens a Microsoft-hosted consent screen that covers both permission sets at once.
We recommend that you give consent using this simple one step process made available by Microsoft. You must be signed in as an Entra Administrator.
The URL listed below uses Almo’s client id (0157755d-f51b-4c9b-b65a-c94de797b221) in the parameters. Once approved this ID will also be visible in your Entra setup.
After accepting, Almo is authorised for your organisation. Users can install from Microsoft AppSource and sign in 🙂
Option 2 – Manual Two-Step Process
If you prefer to complete the setup within Azure and Entra, please follow instructions in this section.
Part 1 – Approve MS Office Permissions
When a user attempts to sign into Almo for the first time, they will see an “Approval required” screen. They can submit an admin approval request from that screen.
When you sign in to Almo for the first time, Microsoft may show an “Approval required” screen.
This is a standard Microsoft security requirement that applies to any add-in requesting organisation-level permissions in Microsoft Entra (formerly Azure Active Directory).
Your IT administrator needs to grant consent once – after that, everyone in your organisation can use Almo without any further steps.
The process has two parts: what we need you to do, and what your IT administrator does.
What We Need You to Do
When you see the screen below after clicking Sign in with Microsoft, type a brief reason in the text box and click Request approval.
A brief explanation such as “I want to use Almo to manage Azure DevOps work items from Outlook” should be enough.
Microsoft will notify your IT administrator automatically.
You will then see this confirmation:
At this point, please forward the page at this link https://getalmo.com/blog/entra-setup to your IT administrator and ask them to follow the instructions below.
The setup takes about five minutes on their end. Once they complete it, you can sign in and start using Almo straight away.
In today’s fast-paced software development landscape, having the right set of tools can make all the difference in delivering high-quality products efficiently. Two popular version control platforms that developers often consider for continuous integration, and project management are Azure DevOps Service and GitHub.
In this blog, we will:
• Compare Azure DevOps Service and GitHub
• Discuss how you can automate manual work using Almo
Azure DevOps Service
Azure DevOps Service, offered by Microsoft, is an integrated suite of development tools that aims to enhance collaboration, productivity, and efficiency for development teams. It provides a comprehensive set of features for version control, build automation, release management and project tracking.
Capabilities and Key Features of Azure DevOps Service
Azure DevOps Service supports both Git and Team Foundation Version Control (TFVC), offering flexibility for teams accustomed to different version control systems. With Git, developers can work collaboratively, leveraging features like branches and pull requests to manage code changes effectively. Meanwhile, TFVC offers a centralized version control system, suitable for projects with specific requirements.
The platform’s Continuous Integration and Continuous Deployment (CI/CD) pipelines empower teams to automate the build, test, and deployment processes, resulting in faster delivery cycles and reduced manual errors.
Azure DevOps Service’s robust project management tools facilitate agile planning, backlog management, and progress tracking. Teams can define user stories, tasks, and bugs, all within a single integrated environment.
Benefits of Using Azure DevOps Service
One of the significant advantages of Azure DevOps Service is its seamless integration with other Microsoft products and services. If your organization relies heavily on the Microsoft ecosystem, the tight integration can provide a unified and streamlined development experience.
Furthermore, Azure DevOps Service allows easy scalability, making it suitable for both small and large development teams. The platform also offers extensive reporting and analytics capabilities, providing valuable insights into project health and team performance.
What is GitHub
GitHub is a code hosting platform that allows developers to collaborate on projects and track changes to code. It is a powerful tool for managing code, and it is used by millions of developers around the world.
GitHub gained immense popularity as a web-based hosting service for version control using Git. Acquired by Microsoft in 2018, GitHub remains an independent platform that provides a robust and developer-friendly environment.
Capabilities and Key Features of GitHub
GitHub revolves around Git version control and offers a user-friendly interface that promotes collaboration among developers. It provides a platform for hosting repositories, enabling developers to work on projects collaboratively and manage code changes seamlessly through branches and pull requests.
GitHub Actions, a powerful feature, allows for the creation of custom CI/CD workflows directly within the platform. This feature empowers developers to automate various stages of their development and deployment processes with ease.
Additionally, GitHub offers a range of project management tools, including issue tracking, project boards, and wikis, facilitating effective project planning and communication.
Advantages of Using GitHub
GitHub’s widespread adoption in the open-source community has cultivated a vast and active developer community. As a result, GitHub serves as a hub for discovering, contributing to, and collaborating on countless open-source projects.
The platform’s user-friendly interface and intuitive workflows make it an attractive choice for developers of all skill levels. Whether you’re a seasoned professional or just starting, GitHub’s accessibility fosters a smooth onboarding process.
Comparison: Azure DevOps Service vs. GitHub
Now that we have explored the key features and benefits of both Azure DevOps Service and GitHub, let’s conduct a side-by-side comparison to help you decide which platform best suits your needs.
Development and Version Control
Azure DevOps Service supports both Git and TFVC, offering options for different version control preferences. On the other hand, GitHub is primarily focused on Git version control, leveraging its strengths in distributed version control for collaborative development.
Azure DevOps Service’s CI/CD pipelines provide robust automation capabilities, allowing teams to streamline their build and deployment processes effectively. GitHub’s GitHub Actions offer similar functionalities, enabling developers to define their workflows and automate repetitive tasks seamlessly.
Project Management and Issue Tracking
Azure DevOps Service’s project management tools are well-integrated within the platform, making it a convenient choice for teams that want an all-in-one solution for version control and project tracking. GitHub’s project management features, including issue tracking and project boards, are user-friendly and suitable for open-source projects.
Collaboration and Teamwork
Both platforms excel in promoting collaboration and teamwork. Azure DevOps Service provides several collaboration tools, including dashboards, wikis, and code reviews, while GitHub’s pull request system and community-driven approach foster effective collaboration.
Which is Better, Azure DevOps or GitHub?
The answer to this question largely depends on your specific needs and project requirements. Azure DevOps Service’s seamless integration with Microsoft products makes it a compelling choice for organizations deeply embedded in the Microsoft ecosystem. It excels in offering a comprehensive suite of development tools with extensive reporting capabilities.
On the other hand, GitHub’s popularity in the open-source community and user-friendly interface make it a preferred choice for developers seeking a platform with a strong community presence and an intuitive workflow.
How Can You Use Almo to Improve Efficiency?
Almo is a single-click addin that seamlessly integrates Microsoft Outlook and Azure DevOps Service. It empowers users to bring work item creation and modification within Microsoft Outlook. Users can effortlessly create new work items, associate them with existing Outlook emails, and fetch real-time updates from Azure DevOps Service. Almo also simplifies finding existing work items.
But that’s not all – as an intuitive Microsoft Addin, Almo takes productivity to a whole new level with its powerful automation features. Leverage the Templates and Auto Pilot engines to automate repetitive tasks, freeing up valuable time for more important work.
Conclusion
In conclusion, both Azure DevOps Service and GitHub are powerful platforms that cater to different development needs. Azure DevOps Service offers extensive integration with Microsoft products and robust reporting, making it an excellent choice for organizations immersed in the Microsoft ecosystem. On the other hand, GitHub’s widespread adoption and user-friendly interface attract developers from various backgrounds.
While both Azure DevOps Service and GitHub play integral roles in empowering modern development teams to build, collaborate and deliver exceptional software products. If you are using Azure DevOps Service then you can improve your efficiency by automating work item management using Almo.Â
Almo is a one-click addin that reduces your manual labour by 15% and saves you up to 200 hours. You can see it in action without any cost. Download Almo and the first 30 days are on us. Enjoy your free trial!
Effective work item management is crucial for any software development project. Azure DevOps Service, a powerful suite of tools provided by Microsoft, offers a robust solution for managing work items throughout the development lifecycle. In this blog post, we will explore the key features of Azure DevOps and provide practical tips for optimizing work item management. From creating and tracking work items to leveraging automation and collaboration, this guide will help you streamline your development process and enhance productivity. Let’s dive in!
Section 1: Understanding Azure DevOps
Azure DevOps is a cloud-based platform that provides end-to-end software development tools, enabling teams to plan, develop, test, and deliver software efficiently. Its work item management capabilities are centred around three key elements: work items, boards, and backlogs.
# Work items: Work items represent tasks, issues, or requirements within a project. They can be customized to suit your team’s needs, with various types such as user stories, bugs, tasks, and more.
# Boards: Boards in Azure DevOps offer a visual representation of work items. You can create customizable Kanban boards, Scrum boards, or task boards to track the progress of work items and gain visibility into the development process.
# Backlogs: Backlogs provide a prioritized list of work items that need to be completed. They serve as a central repository for capturing and managing requirements, allowing teams to plan their work and schedule iterations effectively.
Section 2: Creating and Tracking Work Items
To effectively manage work items with Azure DevOps, follow these best practices:
# Clear item descriptions: Ensure work items have concise and descriptive titles and descriptions. This helps team members understand the task at hand and prevents ambiguity.
# Categorization: Use appropriate tags, areas, and iterations to categorize work items. This enables easier searching, filtering, and reporting, making it simpler to find and prioritize tasks.
# Establish relationships: Utilize parent-child relationships between work items to represent dependencies or hierarchies. This enables tracking progress at both micro and macro levels, enhancing transparency.
# Assigning and tracking progress: Assign work items to team members and set appropriate effort estimates. Regularly update the status and progress of work items to keep everyone informed and identify potential bottlenecks.
Section 3: Automation and Collaboration
Azure DevOps offers several automation and collaboration features that can streamline work item management:
# Automated workflows: Utilize Azure Pipelines to automate the creation and tracking of work items. For example, you can configure triggers to automatically create a bug work item when a test case fails.
# Integrations: Leverage integrations with popular development tools such as Visual Studio, GitHub, and Jenkins. These integrations allow seamless synchronization of work items, enabling teams to work in their preferred environments.
# Notifications: Configure notifications to keep team members informed about changes to work items. Azure DevOps provides flexible notification settings, allowing users to receive updates via email, Teams, or other channels.
# Real-time collaboration: Azure DevOps supports real-time collaboration, enabling team members to discuss and resolve issues directly within work items. This promotes effective communication and reduces delays caused by back-and-forth conversations.
Section 4: Reporting and Analytics
Azure DevOps provides powerful reporting and analytics capabilities to track project progress and identify areas for improvement:
# Dashboards: Create customized dashboards to display key metrics and charts related to work item management. This allows stakeholders to visualize the progress of work items and make data-driven decisions.
# Query and charting tools: Use Azure DevOps query and charting tools to slice and dice data, analyze trends, and identify bottlenecks or areas requiring attention.
# Burndown charts: Burndown charts provide a visual representation of the work remaining versus time, allowing teams to track progress and adjust their plans accordingly.
Conclusion
Efficient work item management is vital for successful software development projects. With Azure DevOps, you have a powerful suite of tools at your disposal to streamline work item creation, tracking, automation, collaboration, and reporting. By following the best practices outlined in this guide, you can enhance productivity, foster effective collaboration, and deliver high-quality software on time. Start leveraging Azure DevOps with Almo and take your work item management to the next level. Happy coding!
