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

Question

Question

How can a forms submitter have visibility to action history of forms submitted by others on their team?

asked on January 31, 2024

We are rolling out a reimbursement forms process to various departments with identified submitters.  Some departments will have multiple submitters.  All submitters have a participant license.  Currently, submitters can only see forms instances and action history for what they submitted.  To facilitate collaboration, they would like to be able to see all forms instances and action history for all submitters on their team.  We want to segregate instance information by team for security and privacy.

Has anyone accomplished this?  Our first idea was to somehow assign a task to the team that completed automatically so everyone on the team would have visibility to that instance.  There doesn't seem to be a way to do this.

Our LF reseller suggests we create a new forms process that does a lookup into the underlying forms database and displays the info in a table (not a report but a forms process that shows data but doesn't actually run).  We need a master/detail view where the master is the subset of forms instances submitted by this person or their team and the detail would be the action history of the instance.

Does anyone have a better idea, or, if not, a database query that returns any portion of the above?  Trying to reverse engineer the database tables to pull the action history seems to be a daunting task.

0 0

Replies

replied on January 31, 2024

You can add them to the process as a business manager then create a custom report with the filters and columns you want to see, from the custom report page you can go from the highest level view all the way into a specific instance action pane.

Looking directly at the database of any software you own (not developed in-house) is not a good idea, the databases of software is an evolving changing thing outside of your control. As the schema changes your custom apps will fail.

0 0
replied on January 31, 2024

My understanding is that a participant license does not allow assigning a business manager role. 

Digging into the underlying database is not our preferred solution for the reasons you mention.  We may decide to pay extra for the necessary licenses to get around this.

0 0
replied on January 31, 2024

I think that is right, participants can only participate in the process, but not be a business manager and have access to everything happening with the process.

You could create your own database and save the state of the information they need as the process moves from step to step, then build a form report looking at that database. Lots of work to build and maintain vs buying a full license though.

0 0
replied on January 31, 2024

Maybe I'm misunderstanding the question/situation.  But could you make each member of the team also a Manager of the team?  Particularly if the team only exists for this particular process, and you want them to have full access to everything the other members of their team is doing, that seems like that would achieve your goal.

0 0
replied on February 1, 2024

The problem we are facing is that a Submitter cannot access reports so we can't do this via report.  Different teams are all using the same forms process and a Business Manager can access everything, including other teams' reimbursement requests, which we want to avoid.

The solution recommended by our reseller is to basically create a report as a very simple forms process which a Submitter can access.

0 0
replied on February 1, 2024

Creating a "report process" isn't a bad idea, and combined with @████████'s suggestion for a custom database solution, it could meet your needs.

During your reimbursement process you have a workflow (or workflows) that save information about the process to a database you control.  You get to decide what information (and how much information) from the process to store.  Then you have the secondary report process that loads the information from the database.

I've done this on maybe two dozen different processes, where they each have workflows that store data.  Some store as little as a "Status" value, and some store nearly every data point that is on the form - just depends on the specific purpose.  Then a secondary process for the reporting is set-up.  Depending on need, you can have the reporting process pull data from the table you created, or a view if you need to rearrange the info or link to other data sources, or even a stored procedure if you want to get really creative.  I like Stored Procedures beause you can make your report include "Search Criteria" fields that control what information is returned from the database.  I'll usually hide the Submit button, since it's just an informational form and doesn't go anywhere.  And I'll usually include functionality to allow the user to download the report as a CSV file.

I'd be happy to provide more information about how something like this could work if you'd like.

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

Sign in to reply to this post.