Implementation of Cross-Departmental Mobile Phone Request Workflow in Jira
Asked by Benjamin H?egh:

I'm currently in the process of creating a workflow for requesting a new mobile phone, but I'm unsure if it's possible to implement this in Jira, especially since the flow needs to cross multiple departmental projects.

I was thinking the reporting manager should use the IT portal to raise a request for new hardware. However, from there, I'm not sure how to proceed in order to maintain a good structure for ease of maintenance and clarity or even how to get it to work.

Here's the flow I'm trying to create:  
![Flow.png](/t5/image/serverpage/image-id/340972i50D2C4F57697ED5D/image-size/large?v=v2&px=999 "Flow.png")


Answers:
author: Lisa Forstberg
body: Hi [@Benjamin H?egh](/t5/user/viewprofilepage/user-id/5095393) ,

I've done this kind of flows a couple of times now in different assignments.

You need to decide if all the users having a role in the process should work as agents in your IT portal project or if there is a need to have different roles in separate Jira projects. With automations you can trigger creation of linked tasks to the original Mobile phone Request to other type of tasks in the same or in a different Jira project. There are pros and cons for both options.

Try to work in all the questions up front on the initial request form to so you don't need to ask additional questions to the requestor (manager/employee) mid life cycle. Using [Forms](https://support.atlassian.com/jira-service-management-cloud/docs/use-forms-in-jira-service-management/) in the request form offers dynamic features, if you said yes to "transfer the old number" then additional fields might need to be visible and be populated.

Some roles only need to approve / decline, like the CEO here in your flow. You should use the [approval](https://support.atlassian.com/jira-service-management-cloud/docs/what-are-approvals/) functionalities that can be configured via the workflow so the CEO can approve it just via a button in an email.

Of course ensuring that the employee is a request participant so they can follow their request is a good thing, keeping them up to date.

Also I would recommend going to Jira cloud premium to unlock the asset functionality in Jira. Having a good list of phone models to choose from with some more attributes around it is cranking up the consumer grade experience and also be a place where IT can manage their pick list of available devices. Taking that to the next step is to also allow for IT to trace what employee has what device, but that is next level in these kind of processes.

Firstly just try to focus on users involved and getting the form in order and the workflow in place.

Good luck!

Lisa

comments: author: Benjamin H?egh
body: Hi [@Lisa Forstberg](/t5/user/viewprofilepage/user-id/5101516),

Thank you so much for your detailed response! Your insights are incredibly helpful as I work on setting up this workflow.

The part where the employee fills out a form is a PDF file that we need to have filled out to give us permission to transfer the phone number. Since we can't just generate our own PDF due to the requirement that it must be the telecom provider's form, I'm wondering how it could be automated, as I see no way to attach a PDF file to an email that we can send to the employee.


author: Lisa Forstberg
body: Hi [@Benjamin H?egh](/t5/user/viewprofilepage/user-id/5095393) ,

Sorry for the late reply!

Aha, the "form" you need to "transfer a number" is like a hard copy form from the provider.

The agent can apply this PDF as an attachment to the issue, ask the Employee to download it, fill it in and upload it to the portal request again.

You say "attach a PDF file to an email", but you don't need an email to transfer information. If the employee is a request participant to the request they will get notified (via email) of what is happening to the request.

I probably would have added a status where its clear we are waiting for the employee to fill out the PDF form, maybe couple that with an automatic comment for the request participants to instruct them what is needed and also add a transition button for them to confirm that they have uploaded the form.

best regards

Lisa


author: Benjamin H?egh
body: I see, that would add a little manuel work but not a issue.   

As some of the infomation is personal i like to avoid having the infomation shared when not needed. Example the addtion to the employee contract do not need to be shared with the IT department. How would this work in Jira?


author: Lisa Forstberg
body: Hi!

In Jira you can work with issue security to limit the visibility into tickets, only including the users involved in the ticket. That kind of speaks for HR having their own jira type ticket.

When the onboarding process involves sensitive personal data you need to have a think about if there really is a need to store that piece of data on the Jira ticket.

I would suggest to talk to HR about the process of signing a contract. Maybe the status of the contract signing should be visible in jira for transparency for all the involved stakeholders, but keep the actual contracts stored somewhere else. HR tend to have other tools for storing \& signing the contracts. Maybe it is better to store a link to that tool if its a cloud based solution f ex.

all the best

Lisa


Tags: cloud

jira-service-management

jira-service-management-cloud