AI Governance

Greetings!

Governance of how an organisation uses AI will be a key factor in how much value/benefit can be realised in the future.

As AI becomes increasingly present in our everyday lives, both at work and at home, more domestic and international governments will attempt to exert control through legislation and regulatory standards.

This will naturally lead to organisations needing to understand, in-depth, how they are using AI and what data sources/structures are being used so they can monitor, manage and maintain compliance with all of the applicable statutes and industry best practices.

Areas that will need careful consideration include the following.

Business case/usage

A clear idea of what AI can and cannot be used for should be established. This should establish firm use cases and decision trees that teams within the organisation can follow if they want to implement AI to tackle specific scenarios.

Intellectual property

An organisations IP must be protected to ensure that, through the use of AI, whether public platform or internet connected private platform, it isn’t exposed to the threat of theft or loss.

Legislative compliance

The introduction of new legislation, such as the EU AI Act, organisations have new statutory obligations to meet or face significant fines and damage to their reputation.

Organisational culture/Skills evolution

At this stage, AI introduces new and exciting, tools that are lauded as being able to improve an organisation’s productivity by percentages that have not been achieved since the Industrial Revolution. However, picking up a spanner doesn’t automatically make me a mechanic! Therefore, an organisation needs to define, implement and continually refresh its culture to ensure that its resources make effective use of these new tools and that the expected Return On Investment is achieved.

An organisations ITSM capability will need to be at the core of this, ensuring that the appropriate strategies and plans are in place to enable business AI agility whilst robustly managing the associated risks.

“But how?!”, I hear you cry…. Well here are some of my thoughts on the subject.

Robust enterprise architecture to provide

architectural patterns and reusable technology stacks, that evolve with business needs and technology improvements

enterprise management solutions that can manage, monitor, alert, and report on the organisations AI solutions

automated and integrated tracking of key data assets that underpin an organisations AI implementation e.g. Large Language Models

Adhere through the use of policy and process controls designed to meet the regulatory requirements of the geographies that the organisation operates in.

Effective audit and reporting capabilities that can analyse information, in real-time, and facilitate escalations, as appropriate, within the organisation so that risks can be managed. The more this can be automated, possibly with the use of AI for analysis, the more robust this will be.

Enforce policies, at the operational and technology levels, to control

usage (appropriate and inappropriate)

data separation to safeguard company intellectual property

user access controls

Invest in the skills of your team, and encourage experimentation with new technologies. AI is growing at an unprecedented pace and so organisations must adapt quickly to meet business demands.

In summary, ITSM capabilities must embrace the organisations use of AI and provide guidance and guardrails. How fast they can evolve with business needs will have a significant impact on the organisations ability to manage risks and realise value from AI.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

JIRA Service Management


Greetings!

Welcome to a new series of articles in which we will look at Atlassian’s JIRA Service Management (JSM) product and I will explain how to set it up so that you can make the most of the products capabilities.

## So what is JSM?
JSM is a service / support desk tool that provides businesses with that capability to quickly implement one or more service *projects* to cater for a range of business function use cases. Under the hood it is essentially JIRA Software, so any organisation that uses JIRA for developing products will find it all quite familiar. 
In my opinion using both modules together is a good basis for implementing a highly integrated support and development model. 

Out of the box it provides an enough basic functionality to engage with customers and log & track issues and requests. However, with the available extensions and integrations, it has the potential to become the beating heart of an enterprise scale IT operation.

In this initial article we will focus on the initial setup of JSM and getting a basic instance up and running. Then, in subsequent articles, we will be going into the various capabilities in greater depth and looking at the options currently available.

## JSM Design Thinking 
While not wholly necessary, if you are an experienced JIRA administrator, I highly recommend creating a design of some sort prior to creating and configuring a JSM instance.

Such a document should consider the following.

* License requirements e.g. how many users and of what type, this includes
  * JSM (inc upgrades for Asset Management)
  * Confluence 
  * Atlassian Guard
* Access management and role based controls e.g. how you want to manage user access and to what level 
* Scope of the Service Desk that will be using the project. Processes, form design, workflows, and required outputs should all be considered 
* What Service Level Agreements need to be tracked and monitored in the tool
* How will users engage with the Service Desk e.g. portal, email, chat, voice etc How your support teams work and what views they require 
* What standards need to be adhered to and therefore what process controls need to be in place e.g. ISE/IEC 20000-1, ISO/IEC 27001, HIPAA, COBIT etc
* Reporting and dashboard needs should be considered
* Integration with other tools, such as
  * Slack or Teams
  * Enterprise Monitoring tools e.g. DataDog, AWS Cloud Watch or Azure Monitor 
  * Email integration 

Creating a document that describes what you will be deploying helps focus the minds of all stakeholders and provides an auditable baseline of what you intended and agreed to do.

## Initial Setup
The first thing you will need to do, assuming you do not already have an Atlassian account, is to register an account with Atlassian and say that you want to use JSM.
Once registered you will be presented with the below choices. Your selection is obviously dependent on what your business driver is for implementing JSM. This series of articles looks specifically at the **IT Support** use case.

![Project Types](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-6_lp6lwh.png)

This selection	takes you to the **Projects** screen. This where you can create and manage all the JSM projects that your business requires.

![Create a project](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-2_sj0q6o.png)

Select *Customer service management* from the next screen.

![Selection](https://res.cloudinary.com/xenos-design/image/upload/v1734982363/JSM/initial/Initial-Setup-Image-3_ksljg1.png)

The next screen tells you to select a Customer Service Management template.

![Template](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-4_zg71fe.png)

We are now at the point where specific information about the project needs to be provided (most of these can be changed later if needed).

- Name - what you want the project to be called
- Key - this will be automatically populated from the name, but you can override it. This code must be unique within your Atlassian account as it is used as a prefix for tickets and is part of the URL for your project and external facing portal
- Team type - select based on your business use case. I am selecting Information Technology (IT)
- Channel access - defaults to Open, which means anyone with your portal URL can submit a request or raise an Incident. I always start with *Restricted* and open up access when the project is launched
- Template - you can select another template type or just with a blank project

![Project info](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-5_xalbtu.png)

Once you click on *Create Project* you are presented with the Service Request types that come with the template. I recommend investigating these and choosing those appropriate to your business use case. To get the most out of these you may need to switch on specific functionality for IT Service Management (ITSM) specific processes e.g. Incident Management, which come with pre-defined workflows.

![Request types](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-6_lp6lwh.png)

Once you have you completed your selection (you can always revise later) click on *Continue to project*. You will see the projects *Get Started* screen. 

![Getting Started](https://res.cloudinary.com/xenos-design/image/upload/v1734982363/JSM/initial/Initial-Setup-Image-7_sg0tvl.png)

## Getting Started
In this section we will go through the specifics of the *Getting Started* screen.

![Let’s get started!](https://res.cloudinary.com/xenos-design/image/upload/v1735036967/JSM/getting-started/Getting-Started-Image-1_fnteyl.png)

The first section of this allows you to walkthrough raising a request, prioritising it using the queues available in JSM and then resolving it. It is quite intuitive so I will not being going through this.

The second section allows you to review essential project configuration data, and consists of three sections.
- Enable customers to raise requests - these are your engagement channels
- Collect relevant information with request types - here you can review your request types and add/remove fields so that the data collected matches your business requirements and data model
- Manage work with your queues and board - this section allows you to review the views that you have for managing requests and Incidents

The third and final section provides links to Atlassian guides, tutorials, community and support pages. These are generally quite good, the ones that I have used at least, so well worth exploring.

Now we will look at the middle section in greater details and discover what the possibilities are.

### Enable customers to raise requests
![Engagement channels](https://res.cloudinary.com/xenos-design/image/upload/v1735038440/JSM/getting-started/Getting-Started-Image-2_o4lndt.png)

This section covers three modes of communication that your customers can engage through. First is the Portal, which a web front end where your customers / users can raise Incidents, requests and search knowledge articles. If we click on the *Customise Settings* button we are taken to a section or the **Project Settings** that is specific to the Portal. This section has two tabs where choices can be made.

#### Portal
##### Portal Configuration

![Portal settings](https://res.cloudinary.com/xenos-design/image/upload/v1735038726/JSM/getting-started/Getting-Started-Image-3_jqwvux.png)

- Portal URL - this is the link to your external facing portal for your service desk
- Service project information
  - Portal name - a mandatory title for your service desk project, this is visible internally and externally
  - Introduction text - the text that customers / users will see under the service desk project (Portal) name
  - Logo - allows you to add a logo to the portal which will sit beside the portal name
- Channel access - clicking of *Edit customer permissions* opens a new page where you can
  - Decide who has access to the portal, and other engagement routes, e.g. Restricted to users who have been given access or Open to anyone who has the link
  - Decide what customers can see within the project. This very much depends on whether your service desk project supports multiple customers or just one and the data privacy regulations that you need to comply with

![Channel Access](https://res.cloudinary.com/xenos-design/image/upload/v1735040287/JSM/getting-started/Getting-Started-Image-5_zhcbzf.png)

- Announcements - controls who can add banner announcement messages to the portal e.g. notifying users of an upcoming service outage or major Incident

##### Portal groups

![Portal groups](https://res.cloudinary.com/xenos-design/image/upload/v1735040889/JSM/getting-started/Getting-Started-Image-6_lrwxht.png)

This tab allows you to add sections to your portal to enable a logical grouping of request types e.g. Incidents, Requests, Changes etc. By default it comes with the General group populated with 7 request types, assuming you have that many in your project. The groups can be re-ordered by clicking on the top left of a group tile and dragging around the page

##### Final View

Once you have configured your portal you can use the Portal URL to see what it looks like. I recommend making changes incrementally and checking the portal after each change so you can see the results in real time.

Below is a simplistic view of where your changes will be visible.

![Portal after customisation](https://res.cloudinary.com/xenos-design/image/upload/v1735041252/JSM/getting-started/Getting-Started-Image-7_dexplf.png)

If you look at the top righthand corner you will see me logged in as a user, a search icon and a Customer button, the latter only being available to those with permissions to add announcements.

#### Email

![Email settings](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-8_xcltez.png)

The Email section provides the capability to manage the email addresses that customers / users can use to report issues and request services.

The default email address is *support@[your-account-name].atlassian.net*. However, this can be amended by clicking the ellipsis, under the **Actions** heading, and selecting **Edit**. This opens the following pop-up from which the email address name can be amended and the Request type that will automatically be created upon receipt.

You will notice that the Request types in the drop down field represent the full list of Request types that were created earlier in this article.

![Manage email popup](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-9_iqhkjs.png)

If you want to create multiple email addresses then click on the **Create Atlassian email** button which opens the same pop-up form.

It is also possible to link external emails to your project, useful if you want to keep a corporate “feel” to the service desk. Simply click on the **Add external email** button, select the option that fits your use case and follow the instructions to connect to your email provider.

![Email integration](https://res.cloudinary.com/xenos-design/image/upload/v1735060223/JSM/getting-started/Getting-Started-Image-10_d4fszs.png)

#### Chat

The chat options of JSM are shown as four streams.

- Integration - with Slack or Teams to give a more integrated feel to the customer experience, crucial in a world where Experience Level Agreements (XLAs) are ever pushing their way into the foreground of CIO thinking
- Workflows - seamless fulfilment of requests within the chat
- Chat to Request - including triggers within a chat to allow agents to generate request records from a chat message
- Virtual Agent - the ever ubiquitous use of AI and Machine Learning to support customers through automation and knowledge bases

![Chat options](https://res.cloudinary.com/xenos-design/image/upload/v1735060739/JSM/getting-started/Getting-Started-Image-11_jhf0wg.png)

### Collect Relevant information with request types

![Request type fields](https://res.cloudinary.com/xenos-design/image/upload/v1735061960/JSM/getting-started/Getting-Started-Image-12_xlm1lj.png)

This section of the Getting Started page is really just a prompt for you to think about what information you want to capture in the forms for the various request types. Clicking on the **View all request types** button takes you to the *Request types* section of *Project settings*.

I will be covering all of the options in **Project settings** in the next JSM article, so we will move on to the next section.

### Manage work with your queues and board

![Queues and board](https://res.cloudinary.com/xenos-design/image/upload/v1735062796/JSM/getting-started/Getting-Started-Image-13_yf7yuv.png)

Both Queues and Boards (now known as Views) are basically ways of view the different tickets yours service desk has open. These can be cut numerous ways depending on how you want to see the information. Both of these take you to the relevant project sections where, assuming you have Admin permissions, you can manage the queues and views.

I will be covering both of these in the third JSM article.

## Conclusion

We have come to the end of the first article in this series. We have explored what JSM is, how to initiate a project and gone through the basic options in the **Getting Started** feature.

In the next article we will be going through all of the **Project settings** options to discover just how versatile JSM can be.

Hopefully this has been useful to you and I wish you well on your ITSM journey…



Greetings!

In this article, the second in my series on JIRA Service Management (JSM), I will be exploring the **Project Settings** available in a JSM project. Due to the numerous options, and level of detail, available in **Project Settings** I am splitting this article into three as follows.

This article will cover

- Details
- Summary
- Features
- Access

The second article will cover

- Request Management
- Automation

The third article will cover

- Channels & self-service
- Operations
- Notifications
- Language support
- Apps
- Versions
- Components

In my previous article I setup a basic JSM project using the ‘out of the box’ functionality and the Customer Service Management template. Now we will go deeper into the available configuration options and discuss what is possible.

It is worth noting that, where additional functionality can be added as part of a paid subscription or license upgrade, I will be covering these in later articles.

## Key Principles 

The following are a few examples of areas that should be considered, ideally as part of your design for JSM as discussed in the initial article of this series, when planning for the configuration of a JSM project.

- Is your Service Desk going to be managing processes other than Incident Management and Request Management e.g. Problem Management, Change Management or Asset Management?
- What information needs to be captured for each process, both at the initial creation of a record and through its lifecycle?
- Are there existing process templates that can be used for the data capture and workflow?
- What queues and views are needed by the teams?
- How many customers are being supported and is there a need to split the data by customer?
- What integrations are needed? JSM can integrate with
  - Collaboration tools e.g. MS Teams and Slack 
  - Enterprise Management tools e.g. DataDog
  - Email integration for a more seamless service experience 

## Project Settings 

We will now go through the sections of the Project Settings menu and see what each sub element lets us configure.

This is accessed from the link shown below, you must have Admin permissions to see this link.

![Project Settings](https://res.cloudinary.com/xenos-design/image/upload/v1735475430/JSM/project-settings/project-settings-image-1_xpai6z.png)

### Details

The first section of Project Settings is Details. This allows you to

- Change the icon that appears in the top left-hand corder of the project screen
- Change the name of the project
- Change the project key, which is the unique prefix to the various record types
- Change the team type to more closely match how you are using JSM and get more tailored recommendations from Atlassian
- Add a URL
- Choose a category, assuming you have some configured
- Add a project description so that users can clearly understand when the JSM project is being used for
- Change the Project lead, typically to the Service Desk Manager/Team Lead or the owning Service Delivery Manager
- Add a default assignee, so tickets are automatically assigned when raised. This can be useful if you have a single person or role that initially triages tickets

![Details](https://res.cloudinary.com/xenos-design/image/upload/v1735476243/JSM/project-settings/project-settings-image-2_rgydgl.png)

### Summary

This section is a one-stop shop to see the key configuration options that are in JSM, whether the defaults or ones that have been configured is subsequent sections.

![Summary](https://res.cloudinary.com/xenos-design/image/upload/v1735476568/JSM/project-settings/project-settings-image-3_tvvyms.png)

### Features

![Features](https://res.cloudinary.com/xenos-design/image/upload/v1735476854/JSM/project-settings/project-settings-image-4_tzxvdt.png)

The Features section is where you switch on or off, and start top configure additional functionality. There are two tiers of features

- Standard, which can be accessed trough the base JSM license charge, and
- Premium, which incurs an uplift to the license charge and gives you access to a range of use features

In this article I will be covering the Standard features only, with the Premium ones being covered later in the series.

#### Views

![Views](https://res.cloudinary.com/xenos-design/image/upload/v1735478574/JSM/project-settings/project-settings-image-5_zrnimc.png)

Clicking on the **Select views** button opens a pop-up where you can select / de-select which of the available view types the service desk agent role can see and use in your JSM project.

![Select views](https://res.cloudinary.com/xenos-design/image/upload/v1735479243/JSM/project-settings/project-settings-image-6-1_tqjb76.png)

#### Work Categories

![Work categories](https://res.cloudinary.com/xenos-design/image/upload/v1735478574/JSM/project-settings/project-settings-image-6_deeukl.png)

##### Service request management

Enabling this feature provides you with a dedicated Service requests space, that can be accessed from the main project side menu, where you can see, raise and manage all service request records, that haven been created, in dedicated queues.

![Service Requests](https://res.cloudinary.com/xenos-design/image/upload/v1735479637/JSM/project-settings/project-settings-image-7-1_dbplf4.png)

##### Incident Management

Enabling this feature does a couple of things.

Firstly, as with service request management, you get a dedicated area in the main project side menu.

![Incidents](https://res.cloudinary.com/xenos-design/image/upload/v1735480160/JSM/project-settings/project-settings-image-7-2_pq1wnn.png)

It also creates a new **Operations** section in the Project settings menu, which we will come to later in this article. However, it is essentially a consolidation of guides and links to other areas of **Project Settings** that relate to the creation and management of Incidents. 

#### Customer Service

![Customer service](https://res.cloudinary.com/xenos-design/image/upload/v1735478576/JSM/project-settings/project-settings-image-7_qrmqrg.png)

##### Customer and organisation profiles

Enabled by default, this features allows the creation of customer and / or organisation profiles from the **Directory** section of the main left-hand side project menu. These are great for holding information of customers that can be pre-populated in a record, information on key contacts, service entitlement information etc.

##### Products and entitlements

If enabled, this features allows the creation of Products profiles from the **Directory** section of the main left-hand side project menu. You can set specific fields for data capture and define who can see the information. There is also the facility to import data, from external sources e.g. a CRM, using an API.

This feature is useful if you need to hold details of entitlement to support for the products that your organisation sells.

##### Developer escalations

Similar to Incident and Service request, enabling this feature gives a dedicated section under **Queues** in the main left-hand menu of the project. From this area you can add or create specific request types for Developer escalations that will be visible in this queue.

![Developer escalations](https://res.cloudinary.com/xenos-design/image/upload/v1735481666/JSM/project-settings/project-settings-image-8-1_uskqif.png)

#### Operations

![Operations](https://res.cloudinary.com/xenos-design/image/upload/v1735478574/JSM/project-settings/project-settings-image-8_oqblot.png)

##### Services

Enabled by default this feature provides the functionality to create a representation of the services that you are supporting, using JSM, and the linkages between them. A good place to start when trying to work out what needs to represented is your Enterprise Architect or ITSM Architect as they should have clear visibility of the service ties, inter-linkages and how best to represent them.

The menu to access this functionality sits in the **Operations** group in the main left-hand menu on the project itself. I will be covering the detail of these in a separate article, but creating a Service allows you to specify

- Name
- Type
- Tier
- Service Owner(s)
- Change approver(s)
- Responders
- Stakeholders
- Repository (BitBucket)
- Description

All of this is invaluable in managing services through their lifecycle.

##### Alerts

Enabled by default this feature provides the functionality to manage IT alerts. The menu to access this functionality sits in the **Operations** group in the main left-hand menu on the project itself.  

Coupled with JSMs ability to interface with Enterprise Management tools, such as DataDog, and the process automation functionality that exists in Atlassian products, you can monitor alerts coming in from your services, perform an action(s) dependent on the data in the alert and auto-assign to resolvers and / or initiate escalations.
##### On-call

Enabled by default this feature provides the functionality to integrate with OpsGenie to manage your on-call rotas for support start and automate ticket assignment and notification outside of your core support hours.

OpsGenie is separate to JSM and incurs additional charges to use. As such it is out of scope of this article.

#### Issue view

![Issue view](https://res.cloudinary.com/xenos-design/image/upload/v1735478575/JSM/project-settings/project-settings-image-9_bmzdeo.png)

##### Suggestions

If enabled this provides your service desk agents with an AI assistant, for Incidents and Service Requests only, that will provide summarised insight into a ticket and suggested actions that can be followed.

It is automatically enabled for Premium and Enterprise plans in JSM.

##### Similar requests panel

Enabled by default this feature provides the functionality provides your service desk agents with a view on similar records, within a type e.g. Incidents.

This visibility is great as it allows agents to identify and escalate trends or major incident scenarios earlier on that just waiting for dashboards to update. It also maximises efficiency as it reduces the need to “re-invent the wheel”, thus giving your customers a better experience.

##### Customer sentiment analysis

This feat is only available for Premium or Enterprise plans, so is out of scope for this article but will be covered in a later one.

I will highlight though that this kind of user sentiment capture and analysis can be a great way to get a balanced view for Experience Level Agreements (XLAs), which I take a look at in a [two part series](https://blog.stevengodson.com/series#XLA) on them.

#### Feature Lab

![Feature lab](https://res.cloudinary.com/xenos-design/image/upload/v1735478575/JSM/project-settings/project-settings-image-10_xeoyng.png)

##### Default request types

If enabled this functionality lets you assign one of your selected request types as a default for certain issue types.
Simply click on the **Default request type settings** button and the following modal will appear, from which you can assign the defaults.

![Default request types](https://res.cloudinary.com/xenos-design/image/upload/v1735561830/JSM/project-settings/project-settings-image-10-1_twg4k4.png)

This functionality takes some of the guess work away from the service desk agents and ensure that requests will be raised in a consistent manner,

##### Request type groups

Enabling this feature allows you to create and add groups that request types can be assigned to. These can be functional, logical, organisational groupings that help your service desk agents provide a more effective service to your customers.

Once enabled, navigate to the **Request types** section in the main left-hand menu and select on of the options.

Click on the ellipsis under **Actions** for the request type that you want to change and select **Edit** under request type group.

![request type groups](https://res.cloudinary.com/xenos-design/image/upload/v1735562863/JSM/project-settings/project-settings-image-10-2_ihmkyi.png)

Then either select the group that you want to assign to the request type from the **Assign to group** tab.

![assign to group](https://res.cloudinary.com/xenos-design/image/upload/v1735563113/JSM/project-settings/project-settings-image-10-3_azmhrx.png)

Or, go to the **Manage groups** tab, click on **Create group** and, once created, go back to the **Assign to group** tab to assign it to the request type.

![create request type group](https://res.cloudinary.com/xenos-design/image/upload/v1735563114/JSM/project-settings/project-settings-image-10-4_epipa5.png)

If you then go back to the **Request types** menu, you will be able to filed your request types by the grouping that you have added.

![filtered example](https://res.cloudinary.com/xenos-design/image/upload/v1735563621/JSM/project-settings/project-settings-image-10-5_tyj7wx.png)

### Access

In this section we look at the Access management options that a JSM Project Admin can see in the Project Settings. These are not the only options available and the next article in this series will look at the options available to an Organisational Admin in the Atlassian settings menu.

#### People and access

![People and settings](https://res.cloudinary.com/xenos-design/image/upload/v1735566618/JSM/project-settings/project-settings-image-11-1_ivlzg7.png)

The **People and access** screen is where users of the JSM project can be managed. From this screen you can

- Add users to the project by
  - Clicking on the **Add people** button
  - adding the email of the users you want to give access to OR add from Google, Slack or Microsoft
  - Choose the role that you want them to have
  - Click on **Add**

![Add users](https://res.cloudinary.com/xenos-design/image/upload/v1735566619/JSM/project-settings/project-settings-image-11-2_tytvoi.png)

- Remove users
- View users by file using the **Roles** filter
- Search for specific users in the **Search roles** field

#### Project permissions

![Project permissions](https://res.cloudinary.com/xenos-design/image/upload/v1735567227/JSM/project-settings/project-settings-image-12-1_ntabbz.png)

The **Project permissions** page shows all of the permissions available in JSM and what has been assigned to which **Project Roles** in your instance.

These can be adjusted to meet your organisational and security policy requirements. Click on the **Actions** button and select **Edit permissions**. The following screen will appear, from which you can Update or Remove assigned permissions.

*Note: caution should exercised with this to ensure you don’t accidentally break your service desk operation*

![Edit permissions](https://res.cloudinary.com/xenos-design/image/upload/v1735567228/JSM/project-settings/project-settings-image-12-2_qgqrzb.png)

Alternatively you can copy permissions from another project, that you have access to, by simply by clicking on the **Actions** button and select **Use a different schema**. The following screen will appear, from which you can Update or Remove assigned permissions. 

The following screen appears. Just select the project whose schema you want to copy and click on **Associate**.

![Copy schema](https://res.cloudinary.com/xenos-design/image/upload/v1735567934/JSM/project-settings/project-settings-image-12-3_ohkotq.png)

#### Customer permissions

![Customer permissions](https://res.cloudinary.com/xenos-design/image/upload/v1735568102/JSM/project-settings/project-settings-image-12-4_ddll34.png)

The **Customer permissions** functionality lets you set the level at which customers can search for other customers. This is set to three levels

- only search within own organisation (default)
- only search within own organisation or enter the email of a specific customer (if known)
- search within the project or own organisation

You can also determine whether the JSM projects portal is restricted to customers that can login or open to anyone who has the URL. The default is to have access restricted. I do not recommend changing this.

![Portal visibility](https://res.cloudinary.com/xenos-design/image/upload/v1735568101/JSM/project-settings/project-settings-image-12-5_zgsjle.png)

#### Issue security

![Issue security](https://res.cloudinary.com/xenos-design/image/upload/v1735569008/JSM/project-settings/project-settings-image-12-6_y6izul.png)

This function requires a Premium or Enterprise plan, as such it is out of scope for this article. By using this functionality you are enabling  security permissions schema that will be applied to your issues. This can be useful for

- Segregation of roles
- Implementing a Security Incident and Event Management process

## Conclusion

We have come to the end of the first article in this series relating to the **Project Settings**. We have explored what JSM is, gone through some of the **Project Settings** feature.

In the next article we will continue to go through the **Project settings** options to discover just how versatile JSM can be.

Hopefully this has been useful to you and I wish you well on your ITSM journey…


Greetings!

In this article, the second in my series on JIRA Service Management (JSM), I will be exploring the **Project Settings** available in a JSM project. Due to the numerous options, and level of detail, available in **Project Settings** I am splitting this article into two as follows.

This first article covered 

- Details
- Summary
- Features
- Access

The second article covers

- Request Management
- Automation

This article covers

- Channels & self-service
- Operations
- Notifications
- Language support
- Apps
- Versions
- Components

In my first article I setup a basic JSM project using the ‘out of the box’ functionality and the Customer Service Management template. Now we will go deeper into the available configuration options and discuss what is possible.

It is worth noting that, where additional functionality can be added as part of a paid subscription or license upgrade, I will be covering these in later articles.

## Key Principles 

The following are a few examples of areas that should be considered, ideally as part of your design for JSM as discussed in the initial article of this series, when planning for the configuration of a JSM project.

- Is your Service Desk going to be managing processes other than Incident Management and Request Management e.g. Problem Management, Change Management or Asset Management?
- What information needs to be captured for each process, both at the initial creation of a record and through its lifecycle?
- Are there existing process templates that can be used for the data capture and workflow?
- What queues and views are needed by the teams?
- How many customers are being supported and is there a need to split the data by customer?
- What integrations are needed? JSM can integrate with
  - Collaboration tools e.g. MS Teams and Slack 
  - Enterprise Management tools e.g. DataDog
  - Email integration for a more seamless service experience 

## Project Settings 

We will now go through the sections of the Project Settings menu and see what each sub element lets us configure.

This is accessed from the link shown below, you must have Admin permissions to see this link.

![Project Settings](https://res.cloudinary.com/xenos-design/image/upload/v1735475430/JSM/project-settings/project-settings-image-1_xpai6z.png)

### Channels & self-service

#### Portal

##### Portal Configuration

![Portal settings](https://res.cloudinary.com/xenos-design/image/upload/v1735038726/JSM/getting-started/Getting-Started-Image-3_jqwvux.png)

- Portal URL - this is the link to your external facing portal for your service desk
- Service project information
  - Portal name - a mandatory title for your service desk project, this is visible internally and externally
  - Introduction text - the text that customers / users will see under the service desk project (Portal) name
  - Logo - allows you to add a logo to the portal which will sit beside the portal name
- Channel access - clicking of *Edit customer permissions* opens a new page where you can
  - Decide who has access to the portal, and other engagement routes, e.g. Restricted to users who have been given access or Open to anyone who has the link
  - Decide what customers can see within the project. This very much depends on whether your service desk project supports multiple customers or just one and the data privacy regulations that you need to comply with

![Channel Access](https://res.cloudinary.com/xenos-design/image/upload/v1735040287/JSM/getting-started/Getting-Started-Image-5_zhcbzf.png)

- Announcements - controls who can add banner announcement messages to the portal e.g. notifying users of an upcoming service outage or major Incident

##### Portal groups

![Portal groups](https://res.cloudinary.com/xenos-design/image/upload/v1735040889/JSM/getting-started/Getting-Started-Image-6_lrwxht.png)

This tab allows you to add sections to your portal to enable a logical grouping of request types e.g. Incidents, Requests, Changes etc. By default it comes with the General group populated with 7 request types, assuming you have that many in your project. The groups can be re-ordered by clicking on the top left of a group tile and dragging around the page

##### Final View

Once you have configured your portal you can use the Portal URL to see what it looks like. I recommend making changes incrementally and checking the portal after each change so you can see the results in real time.

Below is a simplistic view of where your changes will be visible.

![Portal after customisation](https://res.cloudinary.com/xenos-design/image/upload/v1735041252/JSM/getting-started/Getting-Started-Image-7_dexplf.png)

If you look at the top righthand corner you will see me logged in as a user, a search icon and a Customer button, the latter only being available to those with permissions to add announcements.

#### Email

![Email settings](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-8_xcltez.png)

The Email section provides the capability to manage the email addresses that customers / users can use to report issues and request services.

The default email address is *support@[your-account-name].atlassian.net*. However, this can be amended by clicking the ellipsis, under the **Actions** heading, and selecting **Edit**. This opens the following pop-up from which the email address name can be amended and the Request type that will automatically be created upon receipt.

You will notice that the Request types in the drop down field represent the full list of Request types that were created earlier in this article.

![Manage email popup](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-9_iqhkjs.png)

If you want to create multiple email addresses then click on the **Create Atlassian email** button which opens the same pop-up form.

It is also possible to link external emails to your project, useful if you want to keep a corporate “feel” to the service desk. Simply click on the **Add external email** button, select the option that fits your use case and follow the instructions to connect to your email provider.

![Email integration](https://res.cloudinary.com/xenos-design/image/upload/v1735060223/JSM/getting-started/Getting-Started-Image-10_d4fszs.png)

#### Chat

The chat options of JSM are shown as four streams.

- Integration - with Slack or Teams to give a more integrated feel to the customer experience, crucial in a world where Experience Level Agreements (XLAs) are ever pushing their way into the foreground of CIO thinking
- Workflows - seamless fulfilment of requests within the chat
- Chat to Request - including triggers within a chat to allow agents to generate request records from a chat message
- Virtual Agent - the ever ubiquitous use of AI and Machine Learning to support customers through automation and knowledge bases

![Chat options](https://res.cloudinary.com/xenos-design/image/upload/v1735060739/JSM/getting-started/Getting-Started-Image-11_jhf0wg.png)

#### Widget

The **Widget** page gives you the functionality to configure a deploy a widget to the customer portal that can be used to 

- raise an issue with the service desk
- search the knowledge base
- engage with a virtual agent

![Add a widget](https://res.cloudinary.com/xenos-design/image/upload/v1735934803/JSM/project-settings/project-settings-image-21-6_jeouji.png)

*Note: you will need to have portal access set to Open before you can add a widget. This can be set from the Portal settings page.*

#### Knowledge base

The JSM knowledge base is a feature that needs to be enabled but, currently, incurs no cost. It essentially deploys Atlassians Confluence product.

![](https://res.cloudinary.com/xenos-design/image/upload/v1735934998/JSM/project-settings/project-settings-image-21-7_vajnev.png)

To add a knowledge base you will need to

- Click on **Try Now**
- Accept the T’s and C’s on the next screen and wait
- Then, once the last screen appears click on **Go to knowledge base**

You will be taken to the following screen where you can see 

- Create spaces
- Link an existing space
- Set who has visibility
- Select which articles are shown

![knowledge base](https://res.cloudinary.com/xenos-design/image/upload/v1735935242/JSM/project-settings/project-settings-image-21-8_emiuzd.png)

#### Virtual service agent

The **Virtual Service Agent** is an AI driven tool that can enhance the customer experience and shift volumes away from the service desk agents, allowing them to focus on more value add activities. 

However, as this incurs an additional cost it is out of scope for this article.

#### External resources

The screen is used to add links to external tools and / or websites, outside of Atlassian, that customers will find useful. To add one you just need to

- Click on **Add link**
- Populate the form, as shown below, and click on **Add**

![Add link form](https://res.cloudinary.com/xenos-design/image/upload/v1735935805/JSM/project-settings/project-settings-image-21-10_kbiuch.png)

The link will now be visible on the customer portal, as shown below.

![Portal with external resource](https://res.cloudinary.com/xenos-design/image/upload/v1735935805/JSM/project-settings/project-settings-image-21-12_gp7szc.png)

#### Issue collectors

![Issue collectors](https://res.cloudinary.com/xenos-design/image/upload/v1735935991/JSM/project-settings/project-settings-image-21-13_ujdvut.png)

**Issue collectors** are a great way to engage your users, from any website that can run JavaScript, to provide feedback or raise an issue. To add one click on **Add issue collector** and populate the screen that appears.

![Collector form](https://res.cloudinary.com/xenos-design/image/upload/v1735988493/JSM/project-settings/project-settings-image-21-14_ckzp1u.png)

Once you have customised the collector configuration to meet your needs, click on **Submit** and you will be taken the the following screens that provide you with the HTML and jQuery code that you need to include in the website that the collector is for.

![HTML](https://res.cloudinary.com/xenos-design/image/upload/v1735988493/JSM/project-settings/project-settings-image-21-15_sejrba.png)
*HTML*

![JQuery](https://res.cloudinary.com/xenos-design/image/upload/v1735988493/JSM/project-settings/project-settings-image-21-16_jpmsww.png)
*JQuery*

### Operations

In the view shown below only Incident Management is listed. However, if you take out a Premium or Enterprise plan, and switch on Problem Management or Change Management, they will appear in this part of the menu as well.

#### Incident Management

This is a summary page that lists useful articles for managing fields, in both Standard and Premium services, configure responder alerts, set communications preferences and Post Incident Reviews, the latter two being Premium services.

![Incident Management](https://res.cloudinary.com/xenos-design/image/upload/v1735989074/JSM/project-settings/project-settings-image-21-17_nskfny.png)

### Notifications

The following screens are used to configure and enable/disable notifications that will be sent internally within your support organisation e.g. issue assigned to agent or Priority 1 Incident raised, and notifications that will be sent to customers e.g. request created or approval required.

Depending on how your service desk operation is designed, you can switch off all customer notifications or customise the templates (Premium functionality).

#### Internal notifications

![Internal notifications](https://res.cloudinary.com/xenos-design/image/upload/v1735989714/JSM/project-settings/project-settings-image-21-18_q4i5xx.png)

#### Customer notifications

![External notification](https://res.cloudinary.com/xenos-design/image/upload/v1735989714/JSM/project-settings/project-settings-image-21-19_mycocr.png)

### Language Support

This setting allows you to add support for additional languages to your JSM project.

![Language support](https://res.cloudinary.com/xenos-design/image/upload/v1735990449/JSM/project-settings/project-settings-image-21-20_x4jcn4.png)

The main page lists the default language for the JSM project. This is what was selected when the JSM project was originally created. From this page you can

- Change the default language
- Add a new language by selecting one or more of the languages shown in the pop-up when you click on **Add Languages** button, as shown below

![Add languages](https://res.cloudinary.com/xenos-design/image/upload/v1735990449/JSM/project-settings/project-settings-image-21-21_q24iho.png)

### Apps
#### Microsoft Teams integration

From this screen you can integrate JSM with your organisations M365 Teams solution. This gives you the ability for customers to engage your service desk through Teams channels, assuming they either sit on your Teams or allow integration with theirs.

You should check with your IT Security Manager, prior to going down this path, to ensure that you are compliant with your organisation’s information security policies.

Once implemented you can expand the capability through the use of integrated workflows, automation and the AI Agent (additional costs apply).

#### Slack integration

From this screen you can integrate JSM with your organisations Slack solution. This gives you the ability for customers to engage your service desk through Teams channels, assuming they either sit on your Teams or allow integration with theirs.

You should check with your IT Security Manager, prior to going down this path, to ensure that you are compliant with your organisation’s information security policies.

Once implemented you can expand the capability through the use of integrated workflows, automation and the AI Agent (additional costs apply).

#### Development tools

![Repository connect](https://res.cloudinary.com/xenos-design/image/upload/v1735991281/JSM/project-settings/project-settings-image-22-1_y2ekfr.png)

As you can see, this screen lets you connect Developer tools to JIRA.

#### Explore apps

This page lists the additional Atlassian Marketplace apps that JSM can integrate with. If you click on one of the tiles it shows you

- Details of the app
- Privacy and security statements
- Support details
- Version information
- Whether there is a cost for using it
- Additional resources

If you want to deploy one just click on the **Get it now** button to initiate the integration.

![Explore apps](https://res.cloudinary.com/xenos-design/image/upload/v1735991475/JSM/project-settings/project-settings-image-22-2_dom7ud.png)

### Versions

This screen gives you the functionality to list Releases of what you are supporting with your JSM service desk.

![Versions](https://res.cloudinary.com/xenos-design/image/upload/v1735991992/JSM/project-settings/project-settings-image-23-1_x6aerd.png)

You can add a new version by clicking on the **Create version** button and populating the pop-up that opens.

![Add version](https://res.cloudinary.com/xenos-design/image/upload/v1735991992/JSM/project-settings/project-settings-image-23-2_gty2to.png)

Once added you can change the status of the record to

- Released
- Archived
- Merged
- Edited
- Deleted

![Updated list](https://res.cloudinary.com/xenos-design/image/upload/v1735992220/JSM/project-settings/project-settings-image-23-3_xkfuyj.png)

### Components

The **Components** screen is where the components of the service(s) that you are supporting, using your JSM instance, are managed. This list populated the *Components* field that can be seen in the **Request Management -> Fields** menu.

![Components](https://res.cloudinary.com/xenos-design/image/upload/v1735992531/JSM/project-settings/project-settings-image-24-1_k1ebnu.png)

From this page you can *Edit* and *Delete* components.

To add additional components, simply click on **Create component**, fill out the pop=up form that appears and click on **Save**.

![Add components](https://res.cloudinary.com/xenos-design/image/upload/v1735992532/JSM/project-settings/project-settings-image-24-2_wsvnct.png)

## Conclusion

We have come to the end of the fourth article in this series. We have explored what JSM is, gone through some of the **Project Settings** feature.

In the next article we will continue to go through the **Access Management** options to discover just how versatile JSM can be.

Hopefully this has been useful to you and I wish you well on your ITSM journey…


Greetings!

In this article, the second in my series on JIRA Service Management (JSM), I will be exploring the **Access Management** capabilities available in a JSM project.

This will include looking at the Single Sign On (SSO) options provided by the [Atlassian Guard](https://www.atlassian.com/software/guard) product.

*Note: you will need to have Organisation Administrator permissions to implement SSO, as well as having access to your organisations MS Entra ID admin.*

## Key Principles 

The following are a few examples of areas that should be considered, ideally as part of your design for JSM as discussed in the initial article of this series, when planning for managing user access to JSM.

* Managing users should not be an onerous task
* Align with your organisations information security policies 
* Align with your organisations Joiners, Movers and Leavers (JML) process
* Review license usage to ensure you only those that need it have access
* Follow the principle of least privilege access so users only have permission to do what they need to do to fulfil their role

## Available Roles

There are three distinct roles, with JSM, that users can be assigned to.

* ***Administrator*** - access to all functionality plus the ability to access the **Project Settings** and make changes to the project’s configuration 
* ***Agent*** - access to the agent functionality to create and manage request and Incident records
* ***Customer*** - the ability to create requests, view requests that have been raised and search the knowledge base (if access is provided)

These roles can be assigned in a number of ways which we will explore in the next section.

## Basic User Management

JSM provides ‘out of the box’ functionality for managing users. It is accessed from the **Project Settings** menu under **Access -> People and access**.

![People and settings](https://res.cloudinary.com/xenos-design/image/upload/v1735566618/JSM/project-settings/project-settings-image-11-1_ivlzg7.png)

The **People and access** screen is where users of the JSM project can be managed. From this screen you can

- Add users to the project by
  - Clicking on the **Add people** button
  - adding the email of the users you want to give access to OR add from Google, Slack or Microsoft
  - Choose the role that you want them to have
  - Click on **Add**

![Add users](https://res.cloudinary.com/xenos-design/image/upload/v1735566619/JSM/project-settings/project-settings-image-11-2_tytvoi.png)

- Remove users
- View users by file using the **Roles** filter
- Search for specific users in the **Search roles** field

## Single Sign On (SSO)

To use SSO with any Atlassian product a subscription needs to be taken out for [Atlassian Guard](https://www.atlassian.com/software/guard). This provides four methods of authenticating users for SSO. 

From an architectural perspective this sits outside of JSM and can be considered a global Atlassian product as it controls access across all products that your organisation has signed up to with Atlassian.

These setting are accessed via the Atlassian Administration menu.

![Atlassian admin](https://res.cloudinary.com/xenos-design/image/upload/v1735573543/JSM/sso/image-1_y2nfjf.png)

### Domain Verification only

This is the simplest way of deploying SSO as it only requires you to have access to the DNS records for the email domain that you want to use for authentication e.g. stevengodson.com.

In the Atlassian Admin menu select **Settings** then **Domains** and click on the **Verify your company domain** button.

![Verify domain screen](https://res.cloudinary.com/xenos-design/image/upload/v1735573645/JSM/sso/image-2_yc1nz9.png)

Click on **Next** on this screen.

![Screen 1](https://res.cloudinary.com/xenos-design/image/upload/v1735574052/JSM/sso/image-3_jletk4.png)

Enter the domain that you want to verify and click **Next**.

![Screen 2](https://res.cloudinary.com/xenos-design/image/upload/v1735574051/JSM/sso/image-4_xrwen0.png)

On the following screen, select the method of verification that you want to use, follow the instructions and click on **Verify domain** when completed.

![Screen 3](https://res.cloudinary.com/xenos-design/image/upload/v1735574052/JSM/sso/image-5_aygnu8.png)

You should be taken back to the main Domains screen where your domain will be listed. *Note: this may take several hours to verify depending on the method that you choose.

![Domain listing page](https://res.cloudinary.com/xenos-design/image/upload/v1735574652/JSM/sso/image-6_tnjrni.png)

Once your domain is verified you can claim any existing accounts for users under that domain. From this point any users that are logged into their browser using the verified domain can login, using SSO, to Atlassian Cloud.

Access to specific projects within Atlassian will still need to be granted at the project level following the steps shown in the *Basic User Management* section of this article.

### Identity Provider Integration

If you want to be able to control access to your Atlassian projects and products, through your existing federated user management tool, this can be achieved by implementing an **Identity Provider** integration using **SAML** and deploying **Authentication policies**.

This will, with the exception of Google Workspace, require you taking out a subscription to Atlassian Guard, which is licensed based on the number of users claimed rather than active, so I strongly advisee you to check the current pricing and be sure you have a valid business case to proceed.

Once you have setup your Atlassian Guard subscription, or signed up the the free 14 day trial, navigate to the **Atlassian Admin -> Security -> Identity Providers** screen and select your identity provider.

![Identity providers](https://res.cloudinary.com/xenos-design/image/upload/v1735576516/JSM/sso/image-7_dsy5ly.png)

*Note: most of these options will require you to verify your domain prior to setting up any integration.*

If the workflow for your specific integration does not cover setting up *Authentication policies*, I recommend navigating to **Administration -> Security -> Authentication policies** and creating a new policy for your specific *Identity Provider* integration to enforce single sign-on for all sync’d users.

These policies give you control over whether

- A user needs to use Two Factor Authentication
- Login using Third Party login routes
- Use API Tokens to access the JSM APIs
- Set how long users can be idle before they are kicked out. *Note: consult your organisations Information Security Policies to ensure compliance with any mandated periods*

#### Considerations

* If using groups to delineate role access, populate with a test user, wait for it to sync and test the access
* To give sync’d users with a group automatic access to certain projects, you just need to
  * In **Administration -> Directory -> Groups** select the applicable group and give all members access to *JSM* and *Confluence
  * In your JSM project go to **Project Settings -> Access -> People and Access** and add the user group to the appropriate JSM role (Admin, Service Desk Agent and Customer)
* The email addresses of the users, that are sync’d, **MUST** be the ones using a *verified domain*. Failure to do this means users will be treated *External* users and, as such, unmanaged

## Conclusion

We have come to the end of the fourth article in this series. We have explored the User Access Management controls for JSM.

In the next article we will go through the **User Portal** which is the main view for Service Desk Agents when work on different request types.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Creating a NextJS blogging website using Markdown


Greetings!

In this article, the first in a series, I will take you through creating your own blogging website using the NextJS framework and Markdown files for the content.

A preview of the site can be seen at [https://nextjs-13-markdown-blog-website.vercel.app/](https://nextjs-13-markdown-blog-website.vercel.app/).

The advantage of this approach versus using a CMS backend e.g. Strapi, Ghost etc, is that you can build and deploy your site using Vercel without incurring any costs.

Being open there are limitations / compromises with this model, which I will talk about later on, but having built many CMS-based sites I like the simplicity of this approach.

## Now, let’s get started!

Firstly, you will need to clone the template repo that I have created for this article. This repo contains all you need to get started.

So create your project folder and navigate to it in a terminal. Then run the following.

```
git clone https://github.com/wookiehunter/nextjs-13-markdown-blog-website.git
```

Once the clone is complete, run the following to install the project's dependencies and start the project.

```
npm install && rpm run dev
```

Then, in your browser, navigate to [http://localhost:3000](http://localhost:3000) and you will be able to see the following front screen.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/001_kne8bm.png)

We are now ready to move on and look at the project folder and file structure.

## Project Structure

If you haven’t already, open the project using your chosen Code Editor / IDE. I use [Visual Studio Code](https://code.visualstudio.com/) for all Node.js/ReactJS projects.

### Folder Structure

The repo that I have provided comes with the following folder structure.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/002_ivlaou.png)

/*Components*/ - this is where the reusable React components will be kept.

/*MD\_Templates*/ - used to store any templates that you want to use to create your content.

/*node\_modules*/ - this doesn’t come with the repo as it is created when you run the `rpm install` command.

/*Pages*/ - this is the folder where you create the structure and pages for your NextJs project.

/*Posts*/ - this is where we will store the Markdown documents that will be used for your blog posts.

/*Public*/ - this is the folder where NextJs needs files that will be presented by your website kept, assuming you are not using separate storage or a CDN, such as images and Favicon files.

/*Styles*/ - CSS files are kept here. I have used CSS module files, but you can use any approach you are comfortable with e.g. Tailwind CSS, SASS, or Bootstrap.

/*Utils*/ - used to store utility functions used by your project. I have included one for Google Analytics as an example.

### Key Files

The key files that we will be focusing on are:

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/003_nxeabp.png)

/*Components/BlogList.js*/ - this is the component that will render your list of posts.

/*Pages/blog/\[slug\].js*/ - when you click o a post in your list, this is the page that will control how the post content is displayed.

/*Pages/blog/index.js*/ - this is the page that renders when you click on the Blog navigation link. You don’t need to use this if you want to show all of your posts on your home page pages/index.js

/*Posts/0001-my-first-post.md*/ - example of a post.

/*Next.config.js*/ - we need to add a specific config to this the project works correctly.

## How it works…

### Webpack Configuration

The following needs to be added to the next.config.js file. This allows Webpack to use [raw-loader](_https%3A//www.npmjs.com/package/raw-loader_) on .md files and create the arrays of Posts that you will showcase on your website.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/004_gdpwc7.png)

### Using Markdown to create content

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/005_aepw3c.png)

The above shows the format used in the example Markdown post. There are two key sections in the file.

The first section, shown below, is written in [YAML](https://yaml.org/) and can be thought of as metadata. This specific format is used by the [gray-matter](_https%3A//www.npmjs.com/package/gray-matter_) dependency package and allows us to use dot notation to access the values e.g. frontmatter.title etc.

```yaml
---
title: 'My first post..?'
author: 'Your Name'
date: '2021-06-01T12:00:00.000Z'
hero_image: /magic.png
intro: "I did a thing..."
keywords: ""
read: 3
---
```

/Note: when adding images, you can either point to content in the public folder of the project, as shown in the example, or use a URL to content in a CDN, Image site e.g. [Freepik](_https%3A//www.freepik.com_) or [Unsplash](_https%3A//www.unsplash.com_), or cloud-based storage./

The second section is the content of your post and can be written using Markdown syntax, see [https://www.markdownguide.org/basic-syntax/](https://www.markdownguide.org/basic-syntax/) for a basic guide.

Another key consideration is the naming convention that you use for your post .md files.

The repo that I have provided has the following code, in the /*posts/index.js*/ file, which reverses the array of keys that Webpack creates when it interrogates the /*posts*/ folder.

```jsx
export async function getStaticProps() {
    const webpackContext = require.context('../../posts', true, /\.\/.*\.md$/);
    // the list of file names contained
    // inside the "posts" directory
    const keys = webpackContext.keys();
    // this reverses the order of the posts to show the most recent first or alphabetically descending order
    const reverseKeys = keys.reverse();
    const values = reverseKeys.map(webpackContext);
    // getting the post data from the files contained
    // in the "posts" folder
    const posts = reverseKeys.map((key, index) => {
        // dynamically creating the post slug
        // from file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');
        // getting the .md file value associated
        // with the current file name
        const value = values[index];
        // parsing the YAML metadata and markdown body
        // contained in the .md file
        const document = matter(value.default);
        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
```

This is because I use a naming convention that allows for the newest posts to be shown at the top of the web page (the specific format I use is [yyyy-mm-dd-post-name.md](http://yyyy-mm-dd-post-name.md)). If you want to show your posts in alphabetical or some other order, you can amend the code easily.

Just replace the above with.

```jsx
export async function getStaticProps() {
    const webpackContext = require.context('../../posts', true, /\.\/.*\.md$/);
    // the list of file names contained
    // inside the "posts" directory
    const keys = webpackContext.keys();

    const values = keys.map(webpackContext);
    // getting the post data from the files contained
    // in the "posts" folder
    const posts = keys.map((key, index) => {
        // dynamically creating the post slug
        // from file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');
        // getting the .md file value associated
        // with the current file name
        const value = values[index];
        // parsing the YAML metadata and markdown body
        // contained in the .md file
        const document = matter(value.default);
        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
```

At this point, it would be a good idea for you to create some test posts for yourself.

## Showing your content on your website

Now that we have content we can discuss how it is shown on the website.

There are three files that are key to creating, showing, and reading the posts in this project.

The first two are the blog/index.js file

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830044/Post_Content/nextjs-md-blog/006_wrlcdh.png)

And the components/BlogList.js file

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/007_ql0hpn.png)

The first uses Webpack to get the post data and passes it to the second so it can render on the screen.

/Note: you can easily move the code from the first file to your root index.js file if you don’t want a separate posts page./

The third and final file is /*pages/blog/\[slug\].js*/ which shows all of a post's content, at least that which you choose to show when a post is clicked on in the list.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/008_rep2aw.png)

As you can see this has both the frontmatter data and markdownBody content passed into it so that you have access to all of the content in your .md files.

I have used a combination of react-bootstrap and CSS to create a layout and style the content. As mentioned before you are free to use whatever styling approach works for you.

## Let's fire it up…

We are now ready to run the project and see our content. To do this you simply need to:

* navigate to the root folder in your terminal and run `npm run dev`
    
* open your browser and navigate to /[*localhost:3000*/](http://localhost:3000/)
    

The following should be visible on the screen.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/009_kfxxuk.png)

Now click on the Blog link at the top and…

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1689967164/Post_Content/nextjs-md-blog/11_rv0td8.png)

Your posts are showing on your blog page and the content is accessible.

In Part 2 of this series we will be looking at the filters, discussing how these are used and how best to implement them.

Filtering your Markdown posts


Welcome back!

Following on from my previous post [Create a NextJS blog using Markdown](https://www.stevengodson.com/blog/2023-06-15-nextjs-md-blog), I will now show you how to add Category filtering to your blog so that your ordinance can choose to see all posts of a particular type.

Before we begin you will need to have followed the installation steps in Part 1 of this series

## Key Files

The key files that we will be updating or creating are as follows.

**./components/BlogFiltersCategory.js** - this is the component that will render the interactive filter choices in the ./pages/blog/categories/index.js page.

**./components/BlogFiltersMain.js** - this is the component that will render the interactive filter choices in the ./pages/blog/index.js page.

The above two components are essentially the same apart from the href in the Link element, which points to different places.

**./components/BlogList.js** - this will need to be updated to show the categories against each posts card in the list.

**./pages/blog/categories/index.js** - this is the page that will filter your posts, based on the category selected, and render the list.

**./pages/blog/index.js** - this is the main blog page which will require minor updates to enable the filtering.

**./pages/blog/[slug].js** - this will need to be updated to show the categories against each post.

**./global.css** - This is where the styling for the dynamic components will be added.

The posts themselves will require an update to include the appropriate data into a unique entry against which the filtering can take place.

## Creating your filter
### Post Meta Data

The first thing that we will do is look at the metadata, which is at the front of each post, and amend it from this:

![Meta Data!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/001_gvyewg.png)

to this:

![Meta Data!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/002_bojc8s.png)

It is worth investing some time to consider what categories you want to use on your posts so that you have as complete a list as possible before we continue.

## Creating new files
Now we will create the new files needed to make this work.
### BlogFiltersMain.js

Create this file in the /.\/components/ folder and copy in the following code.

```jsx
import React from 'react';
import Link from 'next/link';
import Row from 'react-bootstrap/Row';
import Col from 'react-bootstrap/Col';

function BlogFilters() {
    const filters = ['Technology', 'Business', 'Freelancing', 'Personal'];

    return (
        <Row>
            {filters.map((filter, index) => (
                <Col md={6} lg={3} key={index}>
                    <Link href={`./blog/categories?category=${filter}`}>
                        <div className={`filterTag_${filter}`}>{filter}</div>
                    </Link>
                </Col>
            ))}
        </Row>
    );
}

export default BlogFilters;
```

Some key points to explain are:
* I have used /react-bootstrap/ for the row and column control
* There is an array of *strings* in this file, this needs to represent all of the categories that you want to actively use. This has been used in place of a table that would typically be used database or CMS-based blog. To avoid duplication you could store these values in a /.env/ file
* The /href/ in the /Link/ component points to one of the new files, that we will create later in this exercise, and passes in the filter name as a URL query so that it can be picked up from the context using getServerSideProps()
* The className content is also set dynamically with the styling controlled from the /global.css/ file

### BlogFiltersCategory.js

Create this file in the /.\/components/ folder, copy in all of the content from the /BlogFiltersMain.js/ files, and simply change the following.

```jsx
<Link href={`./blog/categories?category=${filter}`}>
	<div className={`filterTag_${filter}`}>{filter}</div>
</Link>
```

to

```jsx
<Link href={`./categories?category=${filter}`}>
	<div className={`filterTag_${filter}`}>{filter}</div>
</Link>
```


### Categories index.js

Now we will create the page where the filtered list will render.

Create the following folder /.\/pages/blog/categories\// and created an *index.js* file.

Now copy in the following code.

```jsx
import React from 'react';
import Link from 'next/link';
import matter from 'gray-matter';
import Layout from '../../../components/Layout';
import BlogList from '../../../components/BlogList';
import BlogFilters from '../../../components/BlogFiltersCategory';
import styles from '../../../styles/Blog.module.css';

function Categories({blogData}) {
    return (
        <Layout>
            <h1 className={styles.heading}>Tales from the deep...</h1>

            <hr />
            <h5 className={styles.heading}>Filter by Category or <Link href="../../blog">Back to Full List</Link></h5>
            <BlogFilters />
            <hr />

            <BlogList allBlogs={blogData} />
        </Layout>
    );
}

export default Categories;

export async function getServerSideProps(context) {

    const { req } = context;
    const passedURL = req.url;
    let filterName = passedURL.split('=');
    filterName = filterName[1];

    const webpackContext = require.context('../../../posts', true, /\.\/.*\.md$/);
    const keys = webpackContext.keys();
    const reverseKeys = keys.reverse();

    const values = reverseKeys.map(webpackContext);

    const posts = reverseKeys.map((key, index) => {
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');

        const value = values[index];
        const document = matter(value.default);

        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });

    const filteredPosts = (posts, filterName) => {
        const data = posts.filter((post) => post.frontmatter.category === filterName);
        return data;
    };

    let data = filteredPosts(posts, filterName);

    return {
        props: {
            blogData: data,
        },
    };
}
```

This file is very similar to the main *index.js* in the ./pages/blog/ folder. 

The key differences are:

* The use of *getServerSideProps* instead of *getStaticProps*. The reason for this is so that we can access the *context* API and pull the filter name that is passed from the filter components. This gets stripped from the request URL and passed into the *filteredPosts* function so the list of all posts can be filtered
* Use of the BlogFiltersCategory.js functionality. This ensures that a user clicking on categories after the initial filter will not be thrown back to the main blog page
* Reuse the BlogList component so there is a consistent look and feel to the site

### global.css

If you want to follow the same styling approach then copy the following into the *./styles/global.css* file.

```css
.tag_Technology,
.tag_Freelancing,
.tag_Personal,
.tag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
}
.tag_Freelancing {
    background-color: #00796b;
}
.tag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.tag_Business {
    background-color: darkblue;
}

.slugTag_Technology,
.slugTag_Freelancing,
.slugTag_Personal,
.slugTag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
    min-width: 250px;
    border-radius: 5px;
    margin-bottom: 2rem;
}
.slugTag_Freelancing {
    background-color: #00796b;
}
.slugTag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.slugTag_Business {
    background-color: darkblue;
}

.filterTag_Technology,
.filterTag_Freelancing,
.filterTag_Personal,
.filterTag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
    width: 100%;
    border-radius: 5px;
    margin-bottom: 1rem;
    cursor: pointer;
}
.filterTag_Freelancing {
    background-color: #00796b;
}
.filterTag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.filterTag_Business {
    background-color: darkblue;
}
```

If you are using another approach e.g. SASS, Bootstrap, or TailwindCSS then you can skip this section.

## Updating the existing document

Now that we have created the new pages and components we can move on to updating the existing pages and components to bring it all together.

### Blog index.js

Update the *./pages/blog/index.js* page to include the *BlogFilterMain.js* component as shown below.

![Blog Index!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/003_aonw61.png)

### BlogList.js

Now we update the BlogList component to render out the category name that has been added to a blog. I have done this as a conditional statement but, if you are sure it will always be added, you can add it without the conditional.

![Blog List!](https://res.cloudinary.com/xenos-design/image/upload/v1687248085/Post_Content/nextjs-md-filters/004_ua3j8o.png)

### Blog [slug].js

Finally, we will update the page, where all the content of an individual post is shown, to show the category name as well.

![Blog Slug!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/005_lww0os.png)

## Let's fire it up…
We are now ready to run the project and see our content. To do this you simply need to:

* navigate to the root folder in your terminal and run `npm run dev`
* open your browser navigate to *[http://localhost:3000/blog](http://localhost:3000/blog)*

The following should be visible on the screen.

![Working Blog!](https://res.cloudinary.com/xenos-design/image/upload/v1687248198/Post_Content/nextjs-md-filters/006_bagl8o.png)

And that’s it for now… you have now updated your blogging site, using Next’s and Markdown, and enhanced the experience of your readers. Hopefully, you found this article useful and will continue your journey.

In the next post of the series, we will be adding further functionality to your main *index.js* page by adding functionality for * latest posts*.

Thanks for stopping by…


Adding Latest posts…


Greetings!

In this post we will be building on the site created in the first two articles, and demonstrating the benefit of having re-usable components, to add your latest *Posts* to your home page.

## Steps 1 - Get the correct data

Open your *./pages/index.js* file and add the following to the end of the file.

```jsx
export async function getStaticProps() {
	// fetches all the post data from your published article folder
    const webpackContext = require.context('../posts', true, /\.\/.*\.md$/);
    // console.log('webpackContext', webpackContext.keys())

    // the list of file names contained inside the "posts" directory
    const keys = webpackContext.keys();

	// reverse the array of posts so the newest one is first
    const reverseKeys = keys.reverse();
    // console.log('keys', keys)

    const values = reverseKeys.map(webpackContext);
    // console.log('values', values)

    // getting the post data from the files contained in the "posts" folder
    const posts = reverseKeys.map((key, index) => {
        // dynamically creating the post slug from the file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');

        // console.log('slug', slug)
        // getting the .md file value associated with the current file name
        const value = values[index];
        // console.log('value', value)

        // parsing the YAML metadata and markdown body contained in the .md file
        const document = matter(value.default);
        // console.log('document', document.data)

        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
    // console.log('posts', posts);

	// cut the list of posts down to the first 4 in the array e.g. the latest 4 
    const topPosts = posts.slice(0, 4);
    // console.log('topPosts', topPosts)

	// export the data for the 4 latest posts
    return {
        props: {
            latestPosts: topPosts,
        },
    };
}
```

If you encounter issues I recommend using the console logs, already written in, to see where the issues are.

Assuming there are no errors you are now ready to move on to Step 2.

## Step 2 - Use the data

Now that you have the data for the posts, that you want displayed, it can be used to display on your home page.

There are only a few changes required to do this which are shown in the following code.

```jsx
import Head from 'next/head';
import Image from 'next/image';
import Layout from '../components/Layout';
import Introduction from '../components/Introduction';
import AnimatedSplash from '../components/AnimatedSplash';
// Change 1 - import the BlogList component, if not already done
import BlogList from '../components/BlogList';
import Contact from '../components/Contact';
import styles from '@/styles/Home.module.css';
// Change 2 - import grey-matter
import matter from 'gray-matter';

// Change 3 - change "props" to "latestPosts" to directly access the export data from Step 1
export default function Home({ latestPosts }) {
    return (
        <Layout>
            <Introduction />
            <AnimatedSplash />
			// Change 4 - add the BlogList component and pass in latestPosts
			// consider adding a heading before the component
            <BlogList allBlogs={latestPosts} />
            <Contact />
        </Layout>
    );
}
```

## Step 3 - View the data

Now that we have got the correct data, and passed it into the correct component, we are ready to see the result.

- Navigate to the *root* folder of your project
- Run `npm run dev`
- Now go to [http://localhost:3000](http://localhost:3000) in your browser

You should now see something like the following.

![Latest Posts!](https://res.cloudinary.com/xenos-design/image/upload/v1690470282/Post_Content/nextjs-md-latestPosts/latestPosts_kmlyxv.png)

And that’s it for now… you have now updated your blogging site, using Next’s and Markdown, and enhanced the experience of your readers. Hopefully, you found this article useful and will continue your journey.

Thanks for stopping by…

XLAs


Greetings!

This weeks article is dedicated to is XLAs (eXperience Level Agreements) and will answer:

- What are they?
- Should you care?
- How can they be used?

## What is an XLA?
A couple of quotes to start us off…

> XLA is a powerful new addition to the traditional IT Service Level Agreement (SLA). One that builds on the SLA concept by measuring human sentiment and using this to break down silos and think and act from the perspective of a user. 
*Source: [Giarte.com](https://www.giarte.com)*

> Xperience Level Agreement (XLA) is the *concept* of consensus between IT service provider and consumer regarding the desired human experience and business impact.  
> 
> It is also an *agreement* that extends the scope of the output-oriented Service Level Agreement (SLA) to describe the collaboration, experience, and business impact associated with IT services – the outcome. This outcome-oriented document defines the agreed goals, metrics that indicate achievement of the goals, and procedures for collaboration.
*Source: [www.xlaconsortium.com](https://www.xlaconsortium.com)*

In my opinion, both of the above quotes work quite nicely.

An SLA is purely an objective measure based on metrics that are gather from tools (ideally). It should be unimpeachable. 

However, beware of watermelons… which is where your shiny SLA dashboard or report is a field of green, but your customer still isn’t happy! This usually signifies you are not measuring the right things.

An XLA is a combination of objective and subjective measures that give you a balanced measurement of the impact of the service, with a weighting towards how the “users” experiences the service.

## Should you care?
Yes, yes you should… assuming that you are providing a service to a customer  rather than a utility type product that is positioned as being a “service”.

## How can XLAs be used?
XLAs can be used in a number of ways.

- Drive a specific business outcome e.g. adoption of digital channels to drive quicker resolution for users
- Improve the relationship between supplier and consumer by measuring what actually matters to your customers and users
- Gauging the impact of a new supplier or service, so that improvements can be identified
- Measuring the end user experience (UX) for one or more applications, as long as there is a subjective element to the measurement
- Impact of a change programme

The possibilities are varied. The key is having the subjective measure as part of any XLA calculation, ideally captured in a consistent way e.g. using a user survey tool.

However, XLAs should *not* be used as a stick to beat a supplier of services with. Rather they should be entered into as a joint exercise between the Service Provider and Customer to drive improvements.

In future posts I will be diving deeper into this space, so keep an eye open!

Inside an XLA


Greetings!

This week we will be diving deeper into what an XLA (eXperience Level Agreement) should be and look at some examples.

If you are not familiar with XLAs then my previous article XLAs - avoiding watermelons give a useful introduction.

An XLA is a combination of objective and subjective measures that give you a balanced measurement of the impact of the service, with a weighting towards how the “users” experience the service. So let’s look at some examples of what that means in reality.

Balanced Measurement

Objective and Subjective

An objective measure is based on data derived, usually, from the systems or toolsets that are used to manage either ITSM processes, e.g. Incident Management tools, or IT systems, e.g. Application Performance Management.

The objective measures, that help to make up an XLA, are important because they bring context and meaning to the subjective measures.

For example, if you have an XLA that is measuring user satisfaction with your Service Desk, then objectively measuring the number of contacts with the Service Desk gives context.

The context is important because if your subjective result shows 50 negative responses then this sounds, on the face of it, to be a bad thing. Now this result is never a “good” thing but, when taken into the context of 20,000 contacts in the Service Desk in a measurement period, thus meaning a 0.25% negative response, it doesn’t sound so bad.

But, is this really an accurate measure?

Again the answer revolves around context. If 20,000 contacts result in 20,000 survey responses, your subjective source, then this could well be a valid measurement. However, this is unlikely to be the case.

So, another objective measure would be the number of survey responses received in your measurement period. For the sake of novelty let’s say you get 420 completed surveys. Now this changes your perspective quite significantly.

Your original 0.25% becomes 11.9%, which is quite a dramatic change and suddenly things don’t seem quite so good.

However, what cannot be emphasised enough is that XLAs are for driving improvement in areas that are important to the business to that the service(s) are being delivered.

An XLA is neither a carrot to reward a service provider, nor is it a stick with which to beat one. An XLA is a point on the horizon that both customer and supplier are walking towards together. The measurement points are simply there to identify whether they are walking forwards, standing still or are walking backwards.

Source: Steven Godson

So, what we have, so far, is a number of objective measurements, which are as follows.

Total contacts to a Service Desk

Total number of survey results and as a % of total contacts

Total number of positive/negative survey responses and their respective percentages

So, what’s next? Well, the next thing is to define what good” actually looks like in your context and ensure balance in your results.

What is “good” anyway?

What good means, in the context of XLAs, will greatly depend on what you are using XLA measurements to achieve.

However, it is true to say that whatever it is there needs to be acknowledgement that the target chosen should be realistic and is a target to be worked towards rather than there being an expectation that it will be achieved from day one.

It is also sensible to apply a balanced approach to reporting the measures that combine to give the overall XLA measure. A pragmatic way to do this is to apply weighting to each of the component measures based on their importance/significance. The weighting is a % split across the number of measures you are using to calculate your XLA score.

For example, if you are working towards users adopting self-service and digital channels, your XLA measurement may look like this.

Weighting % - this weighting allows you to apply a balanced, business-focused, view whilst maintaining transparency

Metric - the objective and subjective numbers captured in the reporting periods

eXperience Performance Indicator - the XPIs expressed as a % of the relevant total

XLA Score - the weighting applied to the XPI

XLA achievement - the figure that you would be reporting for the given measurement period

The examples of what an XLA could be used to measure are;

Gauging the impact of a new supplier or service, so that improvements can be identified

Measuring the end-user experience (UX) for one or more applications, as long as there is a subjective element to the measurement

Impact of a change program

Summary

In this article, I have talked about what makes up an XLA, and the mindset required, and provided a real-life example. Hopefully, this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

Serial tales from the deep...

Series 1: Building a Next.JS Markdown Blog

Creating a NextJS blogging website using Markdown

Filtering your Markdown posts

Adding Latest posts…

Series 2: Experience Level Agreements

XLAs

Inside an XLA

Series 3: JIRA Service Management

JIRA Service Management

JIRA Service Management

JIRA Service Management

JIRA Service Management

JIRA Service Management

JIRA Service Management

StevenGodson.com