Simplifying Dining Plan Management with Jira Service Management

[#1]

What happens when someone wants to add a dining plan, switch to another option, or cancel a plan they no longer need?

It sounds like a simple request. But behind the scenes, someone still needs to verify the request, find the right user record, update the plan information, and make sure the requester receives confirmation.

When this is handled manually, the process can quickly become repetitive and difficult to track.

This is where Jira Service Management (JSM), Automation, and Assets can work together.

In this article, I’ll walk through a simple and reusable approach for managing dining-plan requests — from the initial request to updating the user's service information.

The idea is simple: let JSM manage the request, let Automation handle the repetitive work, and let Assets keep the current information up to date.

The Basic Idea

A dining-plan service can be designed around three common situations:

• Someone is enrolling in the dining program for the first time.
• An existing user wants to add another plan.
• An existing user wants to remove a selected plan.

The overall experience can look like this:

Submit Request → Capture Information → Automate the Process → Update Assets → Confirm

Let's look at each scenario.

1. When Someone Enrolls for the First Time

Imagine someone submits a request to join the dining program.

Instead of asking an agent to manually create records and update information, JSM can start the process automatically.

Simple Flow

Request Submitted → Collect Required Information → Check for Existing Record → Create Record if Needed → Add Selected Plan → Complete Request

What Happens Behind the Scenes?

Automation can check whether the person already has a service record.

If no matching record is found, the automation can create one and associate the selected dining plan with it.

The requester can then receive a confirmation once the process is complete.

This keeps the process consistent and reduces manual data entry.

2. Adding a Plan to an Existing User

Now consider someone who already has a dining plan but wants to add another one.

There is no need to create a second user record. Instead, JSM can identify the existing record and update the plan information.

Simple Flow

Add Plan Request → Find Existing Record → Read Selected Plan → Update Plan Information → Complete Request

What Happens Behind the Scenes?

Automation can:

• Find the existing service record.
• Check the current plan information.
• Read the plan selected in the request.
• Add the new plan.
• Keep existing plans unchanged.
• Complete the request.

This keeps the user's information in one place and helps avoid duplicate records.

3. Removing a Selected Plan

Cancellation is where selection-based automation becomes particularly useful.

Instead of removing all plan information, the request can tell the automation exactly which plan needs to be removed.

Simple Flow

Cancel Plan Request → Find Existing Record → Read Selected Plan → Match the Plan → Remove Selected Plan → Complete Request

What Happens Behind the Scenes?

The automation can:

1. Identify the existing service record.
2. Read the selected plan from the request.
3. Find the matching plan in the user's current information.
4. Remove only the selected plan.
5. Leave any other active plans unchanged.
6. Complete the request and send confirmation.

This makes the process more controlled and helps avoid unnecessary changes to other plan information.

4. Where Assets Fits In

This is where Jira Service Management Assets adds value.

Think of the JSM request as the action and Assets as the current state.

For example:

JSM Request: Add Dining Plan A
Assets: Person → Dining Plan A

Or:

JSM Request: Remove Dining Plan B
Assets: Person → Remaining active plans

A simple Assets model could contain:

• Person
• Service Profile
• Dining Plan
• Dining Location

The exact structure can be adjusted based on the organization's requirements.

The important part is that the service information stays connected to the person instead of living only inside individual tickets.

5. Let the Request Decide What Automation Does

Another useful pattern is to let the request selection drive the automation.

For example:

Action = Add → Add the selected plan

Action = Remove → Remove the selected plan

This allows the same automation approach to support multiple dining plans without creating completely separate rules for every plan.

If a new plan is introduced later, the process can be extended without redesigning the entire service.

6. Putting It All Together

The complete experience can be kept simple:

User submits request → JSM captures the required information → Automation identifies the user's record → Request selection determines the action → Assets is created or updated → Request is completed → User receives confirmation

The result is a process that requires less manual effort while keeping the service information current.

Why This Approach Is Useful

A dining-plan service doesn't have to become a complicated JSM implementation.

With the right combination of Forms, Automation, and Assets, you can create a simple process that handles:

• New enrollment
• Adding a plan
• Removing a selected plan
• Keeping service information updated
• Sending automated confirmations

The same design pattern can also be adapted for different dining programs and business requirements.

The Key Takeaway

Use JSM to manage the request. Use Automation to handle the repetitive steps. Use Assets to maintain the current service information.

This combination can turn a simple dining-plan request into a clean, trackable, and largely automated service experience.

What About Your Dining Plan Process?

Have you implemented a dining plan management process in Jira Service Management?

What challenges did you face with plan changes, approvals, automation, or keeping user information up to date?

I'd be interested to hear how others are handling it.