I'd like to roll out our Help Desk to general users in our company, but I have one major problem. I don't want employees to be able to edit their help desk tickets after they are submitted. Only IT dept. personnel should be able to edit the ticket. Employees can view their tickets. When a new ticket is submitted, a custom workflow does the following: If user is not in the IT Dept group, the Customer field is set to the Created By person. The Status (Not Started) is copied to a new column Status Old (for comparison in other workflows) There are a number of property lookups so that names display in emails as FirstName LastName instead of domain\username. These lookups are stored in variables. Variable for custom email subject is created. Send an email notification to the IT Dept If the Customer field is not empty, email a confirmation to the user. Here's the problem. The above only works when the regular user has Edit permission. Without Edit, I get an "access denied" error and the workflow stops. I understand that SPD workflows always run as the user who started the workflow. I found a Grant Permission action, but guess what? That only works if the user has Edit permission. Trying to think outside the box, maybe hide "Edit" from the list item context menu, or hide the entire menu, but IT personnel still needs to edit the ticket. Any suggestions on how I can accomplish what I need? This is SharePoint 2007.

Anyone? Bueller? So far, the only solution I have is to set an audience on EditForm.aspx. It doesn't remove the Edit link, but does display a blank page to the user if he tries to edit his ticket. Not an elegant solution, but all I can come up with. Bob

Anyone? Bueller? So far, the only solution I have is to set an audience on EditForm.aspx. It doesn't remove the Edit link, but shows a blank page to the user if he tries to edit his ticket. Not an elegant solution, but all I can come up with. Bob

Hi Bob, I'm not Ferris but I'll try to help..... :) One idea is if you install these (Free) SPD workflow activities: http://spdactivities.codeplex.com/ Within that package is a "Grant Permission on Item" workflow action. Put this action at the end of your workflow to set the user's permission to read. The key is to put it at the end so that the workflow can update the fields without getting the access denied.

Thanks, but I've already explored this. It would be ideal if the user started out with Read, then granted Edit via the workflow and returned to Read. The problem with this solution is that you cannot grant permissions via a workflow action unless the user already has Edit permission to begin with. :(Bob

Sorry, I meant to start with edit. In the list, assign edit permissions to the users... BUT here's the key, in the advanced settings of the list there's a section for "choose which items users can edit" and choose "only their own" (hoping this list has this setting). This way when they create a new item they do have edit access to it. Then in the workflow it bumps them down to read only.

Just after I replied to your suggestion, it hit me that permissions are usually tied to the list item. So, by granting Read at the end of the workflow, the user should not be able to edit any new items they create. Well, I just added "Grant Read Permission on Service Requests to Service Requests:CreatedBy and the user still had an Edit option for the new item, and was able to get to EditForm.aspx. Did I write the action correctly? Bob

Actually, I think the permission is "View Item" and not "Read". I tried that and now the item doesn't even get created. The user gets Permission Denied. Bob

Tried again, this time with "View Items", instead of "View Item". Here's what happens. The item gets created. The user can see his/her item. The drop down menu still shows "Edit", but when he clicks on Edit, there is an error saying the item doesn't exist, and it disappears from his view. As administrator, I can see the item and edit it, but the user can no longer see it. Weird, huh? BTW, the list is set so users can only view their own items. Bob