Just me, or is funny that you don’t see the title / name of the policy on the asset page? Link to the policy, love the newer link to policies folder because you can get title there, but why not there next to the link to the folder? Would be great! Thank you.
PS is it somewhere else on the page, and if it were a snake I’d have been bitten? 
Because it could have multiple policies assigned, right? Could be a dozen different ones. I think that’s why they left that off.
Yes, but they could do a hover to show the names.
Policies aren’t 1-1 with assets, so there won’t be a specific policy assigned to any given asset. There are “effective policies,” which are made up of all the policies being inherited down to the asset. If you click the “View Effective Policy” button you can always see what that is in one click.
But it could be one… haha. Who has 12 policies on an asset?! I need a tutorial, I hadn’t even conceived having multiple policies on one asset. Now I fee like loser, a simpleton! haha. Do you have 12 per asset? Then list 1-3 and don’t show rest? Weird to hold back something helpful from EVERYONE, instead of just the crazy awesome people with 12 policies per asset. lol this is a wild answer I did not expect.
@Jimmie Word jimmie, that’s thinkin! How about show 1 - 3 top prioritized policies, then hover show the rest? We’re already getting somewhere!
@Andy Man, I apparently have really kept things simple lol. I understand the concept of what you said, but have never seen this or thus used it in action… Either way, sure would make sense to show the main one or the entire tree on the page that shows oodles of other details… Now I’m curious if the majority uses it simple or complicated. I use one policy per group of machines, so no asset ever has 2 policies. I don’t understand why you’d do this. Is that what making policies is for? Again, I need a tutorial from one of you wizards with your fancy waterfall policy systems haha.
Lol, there is a lot of flexibility in there when you are ready to utilize it.
Even if we showed the top-most level, that doesn’t necessarily represent what the asset is doing. Doesn’t mean we can look at trying to add all of them in a tooltip or something to be sure it fits.
So for context, a common scenario might be having the top-level policy which is like 80% of what you need running on all assets. Next level down maybe you have a customer broken into multiple sites with their own specific scripts or configs. Next level from each of those is a basic server/workstation breakdown with varying monitors that only apply to each. Then you might have say an on-prem exchange server you need to have special process and service monitors for so you apply a policy specific to that just for that asset.
On top off all that, for most items you can also override them. So if you want all of the monitors flowing down save one or two at any specific level, you can apply a policy that overrides them. That’s why saying what policy is applied at the top doesn’t give you a lot of useful context when inheritance is in play. That’s why we added the button to view your “Effective Policy” on asset records.
Here is a webinar I did with Crystal a while back detailing the feature: Policy Inheritance - Deep Dive Webinar #1 - YouTube
So while I do think there is definitely value is seeing what policy is applied at a glance, it’s also going to have to support the folks that do go 5-6 levels deep in their inheritance scheme as well.
We don’t have 12, but we will easily have 3-4 or more for specialized devices. One policy that everyone needs (Onboarding) then start layering polices for windows updates, 3rd party updates, scripts that should auto run to check things like backups, or error logs etc.
@revivaltechrepair
Our standard setup for clients/assets is to have at least 3 policy folders.
Though my bet due to Human Error on our part is that in some of our clients, RemoteAccess and SystemTray are reversed, and there will be typos in the names too. Unfortunately there is no way to report on this, and have to click into each customer to confirm the structure.
For some clients we have custom Maint policies for different depts or devices, therefore they might have 4 levels.
Something else we do is have 6 Maint Monday policies, and split the client base across all of them.
Maint Monday - Bus A
Maint Monday - Bus B
Maint Monday - Bus C
Maint Monday - Res A
Maint Monday - Res B
Maint Monday - Res C
The intention is that we can role out a changes to Maint Monday to Business Clients and Residential Clients in phases, rather than everyone at once. Then if something bad happens the entire client base isn’t impacted. So if I want to try out a new script, I test it first on our own PCs, then perhaps deploy it to Res A…then if all ok for two weeks, deploy to Bus A, assess impact, then slowly phase in for others.
@andy @kristen.costagliola
SyncroMSP has done a great job building a flexible policy feature. However increased flexibility often generates increased complexity, and the policy features in SyncroMSP are let down by a lack high level reporting of what the policy folder structure looks like over our entire client base, lack high level management tools (UI and API) to make changes, and lack of a system wide Audit Log to immutably record all changes to the policy folders and policies.
Nor is there a high level view of which customers&assets (aka clients) are impacted by each policy.
There has been various FRs and posts created requesting the above be addressed in the UI, in Reports and in the API and usually there is “what I feel” a poor response that nothing of that nature will occur because of “security” blah blah “security” blah blah “MSPs cant be trusted” blah blah.
There are two things we should have done post release and we never got to, but I agree they are holes currently:
1.) Report to show which policies are affecting which assets (regardless of other policies applying in the inheritance tree)
2.) A way to templatize a policy folder structure and apply that in bulk to existing customers, as well as allowing a dropdown selection at Customer creation
Don’t toy with us Andy, these sound amazing! hahaha. That would be awesome, hopefully they show up in not too distant future.
Ahhh ok ok. But you have a policy for JUST remote access, then each folder? And have a policy set at each folder? I’d think to have general policy, like this.
Policy Main 1: Remote access, tray icon general items, windows and third party app gen management
If someone is not going to work with Main 1, like Business C, then I’d clone Main 1, and make a custom policy just called Business C Main 1, tuned to the needs.
If business C has different machines and needs something different, clone Business C Main 1 and make Main 2.
Then these would be dirs in the root of the asset folders, but never got into have nested layers like you’re describing… Not sure I understand the point, if you still have to make custom policies. It’s the same as cloning an overarching policy then make adjustments for different maint scheds and messages or something like that, no? Is there a nerd talk video on this anyone can think to link? If currently I’m too thick to get this over text lol.
I need to go back to inheritance policy fanciness school… haha.
Hmmmmmm interesting and complicated lol. Perhaps it should show the name of the effective policy, just to see at glance before opening page then yea? In my case would be top simple guys one policy, in complicated land would be the lowest most effective and likely remind them of any above that, if not could jump to full asset hierarchy page and what not.
Ah ha! I’ll start with the policy inheritance deep dive vid… Perhaps need to show up to a next office hours for any specifics toooooo…
Ok ok, this is what I’m missing. Why layer when the policy just has all that in there? So each policy can contain all things onboarding, updates, scripts, etc. I’m certaining thinking of this inside some “box” lol.
Remote Access we view as the minimum functionality, and the rest is optional/flexible.
We have a policy for only Remote Access for these reasons.
So the Effective Policy as we call it doesn’t have a name. It would be like if you have your default (top-level policy) and one specific asset has a second policy attached to do something specific, like monitor some process or service that only that machine needs for example. There is no known name for what that policy is.