Security on PPM - Projects and related records
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-27-2016 03:58 PM
My company recently bought PPM. They like it for the most part but have a new requirement.
The problem they are facing is if they use roles then anyone with that role can see the project but they want access to be configured for each Project at row level. The reason for this is they have vendors working on their Projects and they don't want them to see what other vendors/projects they are working with. So basically the Project Manager will decide who can view/Update a Project. Each Project (and related records) will have its own list.
The way I am thinking about designing this is to add a read/write watchlist macro on the form and have Project Managers maintain it. I can turn off all role based security or/and add an ACL that checks if 'User belongs to the list on project' and it looks like I have to add this ACL to all related records to inherit this security (Or maintain a seperate list on each record to provide individual access.control) This would totally override the role based access, I figured I wont need roles since all of the access is controlled by the list on the Project.
I see a lot of limitations and drawbacks of this design as well as but can't think of any better solution.
Looking for any solutions/recommendations/suggestions..

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-27-2016 04:24 PM
So...couple of things here.
1. Turning off all ACLs with PPS could cause a liscening problem with ServiceNow when they run their audits to determine how many role based uses you have and thus the license fee, so I would STRONGLY ADVISE AGAINST THAT. Someone like Emily McMullin would be better to address that than me though, but just know there could be negative impacts there and you should do due diligence there.
2. It would be better to ADD a role with more strict ACL requirements for row and field access (ie project record access). That way you dont nuke the OOB rule SN needs to maintain their business and you can still do the Watch ist thing with OOB watch lists field.....so it woudl be something like this...
ROLE: yourCompanyName_IT_Project_Manager (Do NOT add this to the role of IT Project Manager)
ACL update: row and field level
ACL Field level update to change watch list:
Here is link to ACL process, you dont have to update every OOB ACL for project and field access, you can just create a new one that is more strict.
Please LIKE, and mark helpful if you found it so and mark it answered if this answered your question.
Corbett Brasington, PMP, CSM
Certified ServiceNow Admin
Certified ServiceNow Implementation Specialist
Sr ServiceNow Consultant at Crossfuze
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-28-2016 11:05 AM
Oh sorry, my intentions were not to have any impact on SNOW business.
I didn't quite get the solution though. Even If I create a strict role it will still allow all people with that role to have access to projects.
If I had to configure separate security for each project I would be creating a separate role for each record to meet my goal.
What I can do is add an 'AND' condition on each ACLs, so ACL will check for role and also if user is present on watchlist on the record but that means updating each ACL on Project record. Am I thinking right?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-28-2016 01:04 PM
I can have you a more specific solution by tomorrow, I am currently traveling for work and the internet is really bad so I cannot do what I am suggesting to you in my instance and paste the solution. I will when I return though, just wanted you to know why there will be a bit of a gap from when I give you the answer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2016 09:46 AM
Okay Thanks a lot!