I recently created an Account Request Tool in Power Automate. I have Account 1, Account 2, and account 3. They are all three different SharePoint List under the same site. However when I go to the Power Automate Approval section they are in the same Approval section.
I need to know how can I show Approval just for Account 1 as well for Accounts 2 and 3?
The best solution for your issue is to create separate child flows and merge it into the parent flow. Below is the link on how to create child flow.
How to create child flow
Related
I would like to create an "all#mydomain.com" email distribution list, which automatically tracks changes of all users. I am currently aware of 2 approaches, which both don't serve my needs
Create a Microsoft 365 'group' (which can have a Teams/SharePoint site, etc.)
Create a 'distribution list'
Problem: Both require me to manually add all users, also in the future when new users join the domain.
How can I make a group/team/list/shared address/alias/... which automatically comprises all user accounts, both now and at any time in the future?
I finally found a 3rd option:
Create a "dynamic distribution list" - which allows to define dynamic conditions who should be in the list
This option is not available from within the "Microsoft 365 admin center", but instead (somewhat hidden) in the "Microsoft Exchange admin center".
Requirement for restricting approving a task,
so I have a task in CRM that needs user to approve to process some actions after.
however restriction needs to be applied. based on scenario below;
each user will be grouped in either Level 1,2,3,4,5. (thinking of doing this via OOTB Teams for each level and adding user(s) to each team)
when task is created it will be pre-populated with a particular level (field popualated with level).
user can then only approve tasks that are assigned to their level or below; eg. if user if level 3 they can approve tasks that have been assigned level 1 or 2.
user will approve tasks by populating option set to approved
What would we be best way to achieve this, ideally looking for OOTB method.
I think you need to write server-side code, probably a plugin to achieve this. A plugin will execute regardless of the event source (bulk edit; import; api)
Plugins are also harder to "accidentally" deactivate as they can only be accessed via the Plugin Registration tool
The plugin should be registered on the Update message in the pre-operation pipeline. You will probably need to register a Pre-Image that contains the necessary fields (e.g. Task Level)
The plugin will then:
Read the Level (Level 1, 2, 3, 4, or 5) from the Task (or Pre-Image)
Read the current user's details
Determine if the current user is within the correct team
If the Team is not correct, throw a InvalidPluginExecutionException to prevent the Task Save
This should prevent users (who don't have the right team) from saving the Task
Additionally, the plugin step registration should have an attribute filter so that the plugin only executes when the Approval optionset has changed
I have 2 teams in my VSTS Project: Administrators and Developers.
I need to deny access to the Administrator Backlog to users inside of Developers.
Now any user has access to all teams backlogs and I can't find how to restrict this.
Anybody can help me?
Thanks!
The answer here works, but what do you do when you get 5 teams? 100 teams? For each team, do you Deny permissions to the other 99? Not very scalable. So I tried to find another way and figured out what I think is a better approach.
My goal, btw, was to create a good user-experience for my stakeholders, and constrain what they are able to access and modify. I personally feel that the members of the software engineering team should have access to and be able to contribute to any team... but that's personal opinion.
I got flummoxed, at first, by the fact that teams, when created, get added to Contributors... giving them access to all areas. So first, remove the Team security group from the Contributors group. Second, set the "View project-level information" permission to "Allow" for the team. Last, edit security for the top-level Area associated with the team (sub-areas inherit permissions), add the team group to security for that Area, and "Allow" the following for the team group
Edit work items in this node
View work items in this node
Manage test plans (if we want end-users involved in UAT work within Azure DevOps)
Manage test suites (same)
This assumes, btw, that you've also assigned the top-level Area for that group to that team, and included sub-areas.
At this point, as a member of a team, a stakeholder will only see the teams they are members of, under "My Teams", when viewing boards, backlogs, and sprints. They could go out of their way to browse any other board... but they wouldn't see anything because they don't have permissions to the items on those boards.
Then, I would assign the various stakeholders to the team(s) in which they had a stake.
One could also add software engineering members to teams as well, as this uses an "Allow" approach instead of a "Deny" approach, and so their "My Teams" list would include teams they were members of. Personally, I'd probably go with allowing the engineers to control it themselves through "favorites", rather than having to administer adding \ removing engineers from team security groups.
You can restrict the team users with Area Security.
Follow below steps to achieve that:
Create 2 Groups for the 2 teams: (Admin -> Security -> Create Group)
e.g.: AdminGP for Administrators team, DevGP for Developers
team.
Add the team users to the corresponding Group.
Navigate to Home project, then create Areas for each Team if no
areas created before. (Admin -> Work -> Areas)
e.g. TeamAdmin and TeamDev in below screenshot
Navigate to the specific Team, and set the default Area path for
the team.
Back to home project, Admin -> Work -> Areas, Right click the
AdminGP area -> Security
Add the corresponding Groups for the teams, then set bellow
permissions for TeamDev Group (Developers team):
View permissions for this node - Deny
View work items in this node - Deny
Thus the members in Developers team cannot see the Administrators team's work items in Backlog/Board.
I am working on designing an approval system in CRM and need some inputs on the security design. The entity I am using has User/Team level R/W rights. The overall implementation is bit complex but to keep this question simple, consider the following two parties involved in the system:
Requester: Needs R/W access on requests created by him.
Approver Team: These are pre-defined teams whose users will approve/reject the request. Needs R/W access on requests which need their approval.
Question:
How can I handle providing R/W access for both - Requester and Approver Team at the same time? Since we can't have multiple owners of a record in CRM, the Owner field can only contain either of them (Requester or Approver Team) at one time.
I can think of two solutions to this using sharing functionality and wanted to confirm my understanding:
a. Set Requester as the record Owner and share the record with Approver Team programmatically. The problem with this approach is that even if I share the record with Approver Team, I won't be able to show the sharing details on the main form (which is a requirement).
b. Set Approver Team as the record Owner and programmatically share the record with Requester using Access Templates.
Is there any better solution to handle this requirement, in case I am missing any OOB possibilities?
Well I believe that you can make solution A working with a little bit of coding (I'm not sure if you don't mind coding, but we are on StackOverflow, so I think you should consider that).
First of all the design depends on the simple question - should this Request be shared with multiple teams, or only single team? Single team is simple - just add a lookup on the Request, that will point to a Team. When this team is filled in (I'm assuming that choice of this team is done somehow automatically, but it does not matter as in any scenario you would have to choose the team anyway somehow), you run a simple plugin that shares the record for this team. Sharing using SDK is really simple, just use the GrantAccessRequest:
var grantAccessRequest = new GrantAccessRequest
{
PrincipalAccess = new PrincipalAccess
{
AccessMask = AccessRights.ReadAccess | AccessRights.WriteAccess,
Principal = teamEntityReference
},
Target = requestReference
};
So on the form of the request you will keep the owner of the Request and will have a lookup pointing to a Team that is handling this request. Of course you can further pimp it up by for example un-sharing when the request is accepted or declined or the lookup on the request is changed etc. That would keep the POA table more happy as sharing huge amount of records can lead to fast grow of that table, so it's important to unshare records if sharing no longer needed.
If you want to share to multiple teams, you can still create a N:N relationship between your Request and Team and simply share your Request in a plugin on Associate message between Request and Team (this was a standard option before Access Teams were introduced for the users, remains still the only option for teams). This relationship can be show as a subgrid on Request form (it would look like an access team subgrid).
Of course to prevent users from Sharing the Request record on their own (in that case you will not have the Team in your lookup/subgrid) they should not have Sharing privilege. The plugin should do the sharing in admin context.
UPDATE:
As for the POA considerations from the comments: both solutions will make your POA grow, because for both solutions you will have to share the Request either with the team or with the user. If you will use access team you will still have one POA entry for each Request (so 100K entries per year). I believe that the most important thing here is what happens with the Request when it ends it's lifecycle. If it does not have to be visible to the Team, after it was accepted/rejected then you should simply have a mechanism (plugin or some custom app running on some timely manner) that would unshare all the Requests that no longer require sharing, keeping your POA table in reasonable size.
There is another way of handling your scenario that would not require that much sharing/unsharing logic. You can create a "Request Acceptation" entity in 1:N parental relationship with Request. Because it's parental relationship, user owning Request will see all the "Request Acceptation" and "Request Acceptation" will be owned by proper Team (so only this team will have access). Of course I don't know anything about the business logic, but I assume that "Request Acceptation" can contain only the information relevant to the Team which can be copied in a plugin or workflow.
UPDATE2: As I just saw that you cannot unshare the record at a later stage. But I'm assuming that at some point of time Request is done/accepted/finished/rejected or whatever. If at this point both Teams and User should have access to this Request, then maybe it's a good thing to create some kind of separate entity "Archived Requests", that would not be shared, simply cloned for all the principals that are interested in seeing this information and deleting original Request. There are many variations of this idea, I hope that you get it and can adapt it accordingly to your scenario
Your option a makes the most sense: Requester being the creator, should own the Request. Approver just acts on the Request, so it should be shared with.
About showing sharing details, you can put a subgrid in the form: https://www.microsoft.com/en-us/dynamics/crm-customer-center/create-a-team-template-and-add-to-an-entity-form.aspx
Add a team template to the entity form
Make sure you have the System Administrator security role or
equivalent permissions in Microsoft Dynamics 365.
Check your security role
[read more in the linked page]
Since Requester is a USER an Approver is a TEAM, OOB you can only do option b (assign to the team, share with the user via Access Team).
I can't think of any clean solution involving enumerating the team members and act on each of them, so I won't suggest it.
I am setting up CRM to enable the support team to be able to schedule service appointments. However the problem is that all users in the organisation are displayed as rows. How do I restrict this to just a single CRM Team rather than the whole organisation?
Using Dynamics Online 2016 Update 1.
First create view that shows all users you want and next in calendar view change type to user and pick view that you created. You can't pick teams in there.
I would suggest that you use the Business Unit + Team + Security Role tandem to do this. How do you do this?
Create Child Business Units from the Parent Business Unit.
Create Teams with the same name
Create a Security Role (e.g Service Calendar BU Role) that restricts Service Calendar CRUD, Assign, Share, etc to Business Unit (Note: This entity can be found under Service Management)
Assign that Security Role (e.g Service Calendar BU Role) to the Team