Creating a Project Status PowerApp RO

(0) Share

Report

Posted on by CU30101538-0

Thanks all for your help and direction to my question.

I am trying to create two powerapps:

(1) a request for a trainig project and then,

(2) the actual project work from a designer.

A stakeholder would request the project, this would be the first Powerapp. {However, I am thinking it could just be just a link to the ADD+ item of the SharePoint list.} This request would contain fields that would give the business unit, stakeholders name, main point of contact, and some project information.

The requestor submits the request and would then receive an auto-generated REQ#. I would go into the list and manually choose a designer by editing the row just created.

From the data from the request, a powerapp is created so that a designer can update the work request.

Here’s where my problem arises. I want to be able to provide the requester of the project a stauts update, on a Powerapp, that shows inputs from the designer for their specific project request. The update Powerapp pulls information from the designer Sharepoint list and displays the data as a read only.

This update would be searchable by a learning request number, by the requestor, or keyword of the project.

I know this may sound crazy, but is it doable? I don’t know how to make the requester update powerapp to show just the work updates that the designer has made to their projects.

Thank you for your time and suggestions and any direction you can give.

Categories:

Building Power Apps

I have the same question (0)

All responses (3)

Answers (1)

mmollet 3,187 on at

Like (0)

Report

Here is an example of what I think you want. If I am misunderstanding please let me know!

Have a SP list for Requests
[ProjectName, ProjectID, AssignedTo, DateAssigned, Status, etc...]

The designer is able to pull and edit info from the Requests SP list as he will update the status and maybe a notes field etc to keep the requestor in the loop. The requestor would have access to a new form to send a new request as well as possibly an edit form to edit the request if needed.

Requestor would submit a new request. [mmollet, projectname, Bill Yards, 4/26/2023, New] (status new to start)
The designer would then pull the request down and switch the status to Started.
The requestor would be able to see this status change and once the status is swapped to started, the ticket should probably be locked for editing for all users. This keeps the request as it was when it was started so there is no confusion on what was asked compared to what was provided etc.

Was this reply helpful? Yes No
CU30101538-0 on at

Like (0)

Report

Hi MMollet,

Thanks so much for your ideas.

Are you saying that I wouldn't need a second PA for the designer? I would just do all the work in the Request PA? I never thought of just one PA. I always thought I needed 2 PAs.
Once the request is made, how can I make the PA read-only for the requestor as I want the designer to make all the changes and comments to a notes field. This way, the designer can report all that has been done on the project as he/she progresses. Lastly, is there a way (if you know it) to send an automated email to the requestor saying something like "Your requested has been updated. Click here {a read only PowerApp} to view the status of the request"

Thank you so much!!!

Was this reply helpful? Yes No
Verified answer

mmollet 3,187 on at

Like (0)

Report

EDIT: sorry for the book below 😅

You could do one app or two apps either way. That will depend on if you want the experience to be different for the different users. If the UI is good for both then one app may be easier to develop. For your last question yes you can absolutely send automated emails using flow or power apps either one. The one you use will depend on how exactly you want to send the email. (or when rather). As for how you can make this app one app for all users, see the following ideas:

SP List for requests -> this needs to track who made the request, who is assigned the 'work' to be done on the request, and the status of the request. Anything else you want to store such as date etc is fine as well!
Next thing I would do would be to make a SP list or local collection of names of people that you have as designers. This list will allow the app to know which screens to take the user to as well as what to make editable and visible etc.
When the app loads initially you will have code that will decide if the user is a requestor or a designer. Here is an example: UpdateContext({currUser: LookUp(UsersList, email = User().Email)}) This object named 'currUser' now holds the answers for our next few questions.
The first question is do we want the current user to go to screen A or screen B for example? We can say something like If(currUser.Role = "Designer", Navigate(ScreenA), Navigate(ScreenB)) This will take designers to ScreenA and all other users to ScreenB.
The second question is should the current user be able to edit/make changes to an existing request? Here is another example of how to control this for something like a textinput box: If(currUser.Role = "Designer", DisplayMode.Edit, DisplayMode.View) This will change the textinput box's displaymode property to be edit if the user is a designer and view if the user is a non-designer user.

As for automated emails I would start by adding the Outlook data source called 'Office 365 Outlook'. This will allow you to access the sendemailv2 function which you can use to do the automated email part. For example when your designer takes a new job and wants the status to change they could click a button and this could be the onselect code for the button:
Patch(SPList, selectedItem, {changes to the request go here});
Office365Outlook.SendEmailV2(add parameters here);
The above lines will update the SP item to show the notes and status change then also send an email to whomever it needs to go to. If the entry in the SP list has the requesting parties email it would make it even more simple as you would have the to address, you would have the title/subject for the email, and you could use the notes entered by the designer as the body.

Hopefully this helps explain how you can use this to make a single app that any type of user can use. You can also always make 2 screens instead of 2 apps when you want the users to have different experiences. Hope this helps!

Was this reply helpful? Yes No