Another idea somewhat along the same lines is to use encryption via workflow. Using this one can use a encryption key for a record, and share that key with whoever they need to share it with, thus making it a little more flexible than hardcoded row-level or permission level lock. I have used this successfully.
The drawback to this is if the submitter forgets the encryption key - however this drawback can be overcome by creating a small sub function that allows only the submitter of that row to reset the encryption key. The advantage of creating a reset for the encryption key is to also reset it when you want to stop sharing that row with users it has been previously shared with. This pretty much removes the drawback as well as adds a feature to the functionality. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Ingrey, Rosemary Sent: Wednesday, August 23, 2017 12:26 AM To: [email protected] Subject: Re: [Non-DoD Source] Re: Securing Sensitive WO Information That's a really interesting idea! Thanks for sharing it. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Terry Bootsma Sent: Wednesday, 23 August 2017 6:28 AM To: [email protected] Subject: Re: [Non-DoD Source] Re: Securing Sensitive WO Information While entry row-level access can do what you want, I've implemented something different that might meet your needs and you may want to think about. I've created a special type of Work Log (Secure Work Log) and only allowed users with certain permissions to view, report, etc. on this type of work log entry. This has the benefit of having people being able to interact with the application and entry (Incident/Change/Work Order) as a whole without the pain of hiding/unhiding/etc. the entry as it is passed between various groups. Any "secure" information needs to be put into the request via the "Secure Work Log" entry. This might work in your situation, based upon your requirements. Something to think about. Terry -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rackley, James A CIV Sent: August-22-17 8:41 AM To: [email protected] Subject: Re: [Non-DoD Source] Re: Securing Sensitive WO Information Roger is correct. Configuring multi-tenancy is not worth the ROI in this instance. Neither is Case Management. We were hoping for a simpler solution at the Support Group level. Regards, Jim -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Roger Justice Sent: Friday, August 18, 2017 4:14 PM To: [email protected] Subject: [Non-DoD Source] Re: Securing Sensitive WO Information ** His statement is specific Support Group not separate companies. -----Original Message----- From: Deepak Pathak <[email protected]> To: arslist <[email protected]> Sent: Fri, Aug 18, 2017 3:52 pm Subject: Re: Securing Sensitive WO Information ** I believe that feature is called Multi-Tenancy. On Fri, Aug 18, 2017 at 10:34 AM, Rackley, James A CIV <[email protected]> wrote: Oh Mighty Brain Trust, What is the recommended method to ensure that users with Work Order permissions CANNOT see a specific subset of WOs via Global Search, WO Console, Overview, AR Reporting, Analytics, or Smart Reporting? Essentially, only users in a specific Support Group should be able to see anything at all about WOs assigned to this Support Group. Thanks in advance! Regards, Jim Rackley, PMP CGFIXIT Service Manager USCG, C4ITSC, Business Operations Division "You can't help everyone. But everyone can help someone." ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.arslist.org&d=DwMCa Q&c=0NKfg44GVknAU-XkWXjNxQ&r=iuYYqFqKHbSOeyo5LY9dkV5F4FpNAQQwkv53Lj1KZMQ&m=b hbd2MzApvpTGxeBSWoFc2I-6QzdkhsaQKFVVHfXFuY&s=Me9JYEPDXPdI2JMa6-H17FULCBbOSVM PpO-lnzyqdD8&e=> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" Confidential communication Westpac Banking Corporation (ABN 33 007 457 141) Westpac Institutional Bank is a division of Westpac Banking Corporation ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
