nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Portal Request Permissions

Alex Mihailoff

I am building out a new user hire form. HR was testing it today and went the form was sent to the approver via an automation rule. They select or type out an email within the organization on the form. That person gets sent an email with a link to the request which, ideally, they would be able to see in order to complete the form and submit it for us to process. This is where the issue lies.

When that person clicks the link, they receive a message that they do not have permissions to view the request. This is extra strange because I had tested this and had not seen this issue before.

I have set a security scheme that I thought would allow all "Service Desk Customers" to view and edit the New User Onboarding request. That didn't work. It falls under a "Service Request" request type.

Where do I specifically go to address the permissions I need to make this work? Or is it not possible?

Accepted answers

All comments

Mathew Lederman

@Alex Mihailoff typically tickets on the service desk portal are only visible by those who are involved in the request itself. The reporter, anybody who the request was shared with, approvers, and agents working the request.

If you want all users to be able to see every request, it sounds like you want to utilize JSM Organizations and simply share every request with the organization. This would allow every user in the organization to see every request raised.

Alex Mihailoff

The field that the email is put into is linked to the Approvers group. Does that not make them an approver? Is there a permission I can check to ensure that's what is happening? Perhaps it isn't properly associating that person as an approver.

Opening up every request to be visible to everyone in the organization sounds like a blanket option that could create issues. It certainly is easier but it's significantly less secure. That being said, am I interpreting that incorrectly? What settings would I need to enable to make that possible but also not alert everyone in the organization that a request came in?

Mathew Lederman

Apologies, I misread your original question incorrectly. You're right, giving everyone access to everything is significantly less secure and it doesn't sound like that's your goal.

I believe the piece you're missing is in the workflow. JSM workflows have an Approver selection on each status where you can define a user/group custom field that should be given approval permissions. Putting your 'Approver' field in the workflow at the appropriate status should solve your issue.

To answer your first question, no adding a user to the 'Approver' field doesn't do anything by itself. You have to also define the Approver field in the workflow as the appropriate approver selection for that specific status.

Alex Mihailoff

Ok, all of that makes sense. Now let me throw the curveball.

This started as a workflow with an approval step. The way we're trying to make it work is one person fills out part of the form and creates the request. The hiring manager would then fill out the rest of the form and do the final submission which would then tell us in IT that everything was ready for us to begin configuration.

With the approval step enabled, what would happen is the hiring manager, who would be considered an Approver based on linked fields, would get the form and be able to submit just fine but then they would have to refresh the page and click Approve to progress the status. I removed the approval step by unchecking the box in the workflow which now has caused this issue.

Using the logic that a completed and submitted form means it is also approved, I'm trying to remove the need to both submit and approve.

Perhaps I could configure an automation rule that when the form is submitted, the request becomes "Approved" automatically and then moves to the next step. Could that be the way to go?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management