Part 3 – Company Portal Criteria

Introduction

In the previous part we covered all around how we structure applications that we deem to be as required and how we have the groups designed for not only the appropriate understanding of its deployments but how we avoid clutter to our work flow.

This part focuses on the other side of the spectrum, the applications available across all users via the Company Portal.

Here we will outline how we define this criteria as this is the foundation we must set before we calibrate and move forward.

Building Blocks for specific areas of application management

Here we are really defining how we view “Available Applications” in Intune. Available applications are those having the overall option of installing them at leisure through the company portal which can be done from either the application version or web version.

But what we want to do here is to further breakdown as to why they should be made available in this way. What would be the criteria for why certain applications should be made available. Below we have a few defined categorized reasons as to what would make them worthy.

Non Business Critical Priority

Some applications can indeed enhance the performance of ones ability to perform their role. However in cases where certain applications are not deemed as “essential” then the priority of them can be scaled back to me made available.

This is perhaps the most common reason as to why applications are made available. However as general best practice I would recommend to not make many applications in this way as you can potentially invoke the idea of users pulling down a lot of applications which could complicate performance issues on devices. Application management has to be done correctly overall, but the foundations and prerequisites have to be indeed done first.

License Limitation on Applications

Now this, is also another very common one indeed. Applications which have a certain amount of licenses indeed have to be managed very carefully. This is really what application management is all about – not just the deployment of applications but the overall understanding as to where they have been deployed too and perhaps an intermediary where an approval workflow process and audit can be maintained in between these areas.

And this is where we will be getting very heavy into this next part.

Role Specific Categorization

Perhaps a mixture of both categories above this. But for further explanation of this it really comes down to where available applications can be more organized in a productive way which is more engineered to being role specific.

Of course you can build out Autopilot deployments or required deployments which can apply to specific role management based groups. They would get every application which that role requires. However, the principals of priority come into play where you would have to make a decision as to whether you want to complicate or possibly pollute a workflow with applications which may not be necessary for that moment.

This area is more of an organizing or layout perspective but it does indeed add to the overall enhancement of true application management. If the default categories are not enough then feel free to expand to make some more departmental based ones which are more representative to your end client requirements.

Enriching Information of Applications in a Company Portal

Whether it is well known applications or bespoke applications its very very important that they are laid out and presented in the most user friendly way possible. Application information which is clear and concise really is key. Small details in these kind of things do matter though it can take work, it’s worth it.

Key areas I see here besides the Name of course are the optional areas such as;

• Description
• Publisher
• Category
• Information URL
• Privacy URL
• Developer
• Logo

it’s important to take into consideration that when users go to locate these applications that they know what it is, what it does, and how it can actually benefit their role. Imagine for example this was a bespoke application. Chances are it may not contain a logo or a thorough enough description, and then these can very easily be overlooked. Believe me it does happen 🙂

These types of applications may get mentioned perhaps in inductions, training, on-boarding processes and many other areas. This is why these areas of interest make a big difference.

Group Assignment and Naming

Very similar to the required deployment practices, a clear naming convention is always best.

However there are a couple of ways you can define grouping for scenarios like these.

Role Management Group

As we covered more role specific areas, you could create a new group whether that be dynamic or assigned so that it only covers users which are specifically grouped by its role function. So if a sales department had specific applications which were made available to them, then you could have a group which has every available application being assigned to it.

A group following a naming convention of “Test Company – Sales Users” could be a good way of defining its role and knowing of the type of users to add to it.

Application Based Group

The traditional way is to have a group where the naming convention would simply be based on the application.

For example VLC Media Player being made available could be something like “Test Company – VLC Media Player – Company Portal“

This works well – more for required than available deployments. I guess the logic would be if you are going to add them to a group which references a specific application, then why would it need to be made available? But requirements can differ from client to client. This scenario may be more fitting towards the limited licensing scenarios.

Next On Part 4

Part 4 will be discussing specifically how we handle applications with limited licensing. More importantly, we’ll discuss how we are able to implement an approval workflow between the request and the deployment.