You are viewing limited content. For full access, please sign in.

Question

Question

Large amount of group access

asked on June 6, 2024

Hello,

I am working on a process to automate our AP, which requires me to give access to each budget manager to their own GL folder for those applicable documents.  We are looking at around 1,500 GLs, possibly with individual managers for each.  My idea is to create folders for each GL and then corresponding groups in LFDS to manage.  

1. Does anyone have a better idea on how to handle this situation?

2. Is there a limit on how many groups LFDS can handle?

3. Is there a mass way to create groups within LFDS?

Thank you for your insight!

0 0

Replies

replied on June 7, 2024

Do you have Active Directory? Are the GLs they are responsible for tracked in AD in some way, maybe via department, job title, or some other attribute? If so, I would start by creating dynamic AD groups for GLs so the memberships are automatically updated; assuming consistency in your AD data, this can easily be scripted. This would get around Blake's point that the LFDS groups would have to be manually updated whenever someone changes position, since the membership would be maintained through AD, not LFDS.

Once you have that done, you could use a workflow to automate creating the folders and assigning rights for the AD groups.

You might still want to add all of the GL AD groups to a parent group that you'd also add to LFDS to ensure licensing is assigned correctly and to control access to the GL parent folder.

1 0
replied on June 7, 2024 Show version history

Emilee,

I guess what this might come down to is who do you want to have the burden to update the groups or the SQL table when needed? The Laserfiche Admin, IT, etc. And where do you want the groups to live?

1 0
replied on June 7, 2024

We built something for a process that we ultimately didn't end up using. For that process, contracts would be filed in the repository, and ANYONE in the organization (2,500 + users) could be selected as a reviewer of the contract, so we had to allow them temporary access to the repository folder on-the-fly. Here's how we managed that:

On the form, the reviewer was selected and we pulled their AD username into a hidden field.

In Workflow, we used "Retrieve Business Process Variables" to pull in that username, plus all the fields needed to point to the repository path where the document was saved.

We then used "Assign Rights" in Workflow to assign that AD username permissions to that specific repository folder.

After the review step was complete, we ran a similar Workflow that used "Assign Rights" again to remove those permissions. 

This was built and tested, but as I said, didn't end up actually getting used.

1 0
replied on June 6, 2024

What are you using the folders in the repository for?

0 0
replied on June 7, 2024

Blake,

My thought process is to have the folders contain completed payment request and purchase orders.  Purchasing and AP would like budget managers to only see their budgets (GLs).  The folders will be for each GL for access purposes.  To help with management, I was then going to create a group for each GL to have access to those folders.  This way if the budget manager changes, it will be easy to give the new manager access to their past documents.

I am open to any suggestions or insight, especially if I am way off track on how to handle this :-)

Thank you!!!

0 0
replied on June 7, 2024

That sounds like an administrative nightmare. If there is any way to talk them out of that type of security, I would. Each time someone switches position the group will have to be updated as well as when new GLs are added or removed.

If this really is "the way", I would handle it one of two ways. The first is what you said. The second, would keep LFDS groups cleaner, but goes against security best practice of using groups. You could create a SQL table that lists each GL and the user that should have access to the GL folder. A workflow could then be run to go through each of the GL folders on a schedule and update the access rights for the GL folders. When someone changes or GLs are added or removed, the SQL table would just need to be updated.

3 0
replied on June 10, 2024 Show version history

Seconding that on the few occasions we've done this where we haven't had direct access to query the ERP database (or View thereof), building out the business logic and integrations to "sync" GL approvers from the AP system of record (SAP, etc.) to a SQL table Laserfiche could query was a huge undertaking. Hundreds of hours of effort all-in to develop, thoroughly test, and maintain.

Though it's certainly doable as a core part of a core business solution, I would go to great lengths to identify any adequate alternatives before going down that road.

0 0
replied on June 10, 2024

The approval process using SQL views to determine its approval hierarchy using the information inputted into our ERP.  I may attempt to use the same view to determine the repository access as well.

It would seem using our source of records would be the best way to maintain this access.  Am I missing a reason it may not be?

0 0
replied on June 10, 2024

If you have direct access to (views) of the ERP SQL database, that certainly simplifies things and avoids the need to sync your own table.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.