• State Not Answered
  • Replies 13 replies
  • Subscribers 4 subscribers
  • Views 5025 views
  • Users 0 members are here
Related Discussions
Home » Discussions » Reports

194424 - no subject - I am creating a Tempo Report for listing

miteshp
I am creating a Tempo Report for listing all the active tasks in appian from all processes along with the corresponding owners for those tasks.

It seems when we view the report using System Administrator's account, Appian lists all the tasks from all processes. But when we view as a basic user, it lists only the tasks from process models you are privileged to. A shorter list. Which is as per Process Model Security (Viewer Role) theory.

The requirement is to have this report for management where users are not authorised to perform any actions/related actions but they should be able to see what's happening and what tasks are still pending and with whom.

It seems if we associate a group as viewer to a process model they will be able to see the reports on those models but will also get the access to initiate the related action.

Can we create a custom role in Appian for process model security with access to view reports? Is there any other way to achieve th...

OriginalPostID-194424

  Discussion posts and replies are publicly visible

  • 0
    Hi Mitesh,

    What you can do is that you can create a new group (let's say Auditors) and add that to the process model security (probably the initiator role). And you can have the same group access to the task report as well.

    Now to prevent the users of this new group from starting the process, you can alter the visibility expression of the related action in a way that only the users belonging to this group cannot see the related action. You can use the expressin - isusermemberofgroup(loggedInUser(),cons!AUDITORS) , provided the constant holds the value of your new group.
  • 0
    I would like to make few tweaks as per my knowledge to the above mentioned procedure as follows:

    1. I guess the group should be given Viewer access rather than Initiator. For instance, a Initiator of a process can't view a task report that contains task for the corresponding process.

    2. The rule that's going to filter the groups should be a platform level reusable rule.
  • 0
    @miteshp An other way to skip the addition of an extra group to process security role map and thereby filter the same in the visibility of the Appian objects is, you could add the entire task information to database but we miss the changes that takes place in the attributes of tasks such as deadline, priority, assignees, owner etc until and unless the updates are made. I wouldn't opt for this generally.
  • 0
    Certified Lead Developer
    Brainstorming here, what if you executed the reports as part of a process model so that it could execute the report in the context of the PM designer, and save the results into some data subset that could be viewed by a non-priveleged user?
  • 0
    Hi Guys,

    Thanks for spending time and providing a response. But let me add some more insight to the problem and the approaches that has already been suggested, discussed and ruled out.

    Requirement is to show the information in the reports tab as tempo report. To use a process model to execute as a process designer we will have to show the report in the related action or action tab.

    If we add a group to process model security it will give the group the access to trigger the related action even for the very minimal role. We can't leverage the visibility condition as this will have maintenance problems later.

    Storing the task information in DB will kill the runtime analysis aspect of the report.

    We already have provided an export to excel link which will download the full report in excel running the process as designer. But how to show the same in SAIL.
  • 0
    Thinking loud, but also suggested another approach to get the full result set in SAIL form in report section. Can you guys let me know if this seems a good approach.

    Create a CDT with the fields to be shown in the report. Create a process model with a process variable as a list of that CDT. Execute the process as designer and use process analytics to populate the process variable with full result set. End the process.

    Create a process report which gives a process instance with populated process variables taking an instance Id.

    Expose the first process model as a web service.

    Create an expression rule that call that triggers the created service using "websevicequery" function taking the authentication credentials and returns the process instance Id.

    Continued.....
  • 0
    In the SAIL form associated with the required report. Call the expression rule to get the process instance id. Call the process report created earlier using the query process analytics function and passing the retrieved process instance id as query parameter.

    Get the process variable containing the required complete data set from the retrieved process instance.

    Use the data to populate the grid.

    It seems arguably best workaround to achieve the desired goal, to me. Opinions appreciated.

    Thanks!!
  • 0
    @miteshp As per my knowledge, exposing the process model as webservice isn't needed. You can replicate the same functionality by using the 'startprocesswrite' function at https://forum.appian.com/suite/tempo/records/type/components/item/i8BCLGOdlMUpdGVqT-RV7oRg74uEGJO5yQeCToV_iK9c-uZFaHQndbxbAQOV2CNBg/view/summary and this will trigger a process instance.

    The only downside of the approach(specified by you) I can see as of now is, the process maintains huge chunks of data in form of PVs which is obtained from querying analytics which thereby makes the process heavier. I hope you are aware of this.
  • 0
    Startprocesswrite function requires one click from a user to trigger the process. Moreover it seems it doesn't return the process id to be passed to the later rules. I fear this approach doesn't work.

    Regarding the memory issue we can archive the process after a very small duration. As every time the user refreshes the page it will create a new process instance and soon as you fetched the instance in query analytics you don't need the process in memory anymore.

    Can you please share your thoughts on this.

    Thanks!!
© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.