Having your own PowerShell Interface

Does your application have its own set of PowerShell commands?

Have you ever considered it?

In this post I want to highlight why you should consider it and how it can be a great benefit for, not only your application, but your support and helpdesk staff also.

First, what is PowerShell?

PowerShell is a task automation and configuration management framework from Microsoft, consisting of a command-line and associated scripting language

OK, Let’s get on with it!

Having a scripting interface for your application can be an incredible powerful way for both your staff and customers to use your application, either cloud-based or desktop based!

Staff can use it to automate common tasks, fix errors with precision and use it for performing bulk operations on the dataset.

Customers can use it to get the exact data they want out of application for their decision, reporting and dashboarding needs.

While I freely admit, a PowerShell interface is not the best way for your customers to interface with your application, it’s a way Champions and Power Users of your application will find it invaluable.

You want the warm fuzzies about your application being able to provide the data people want, when they want, in a format they want (CSV... most of the time)!

Also, I want to point out, you should have some sort of privilege system built into as well, Helpdesk/Support staff should have access to commands, customers do not have access to.

Reasons why (Staff):

·        Build scripts to perform complex tasks to increase efficiencies in the workday

·        Build automation scripts to take care of mundane task, saving time and money while yet again increasing efficiencies

·        You can remove (or at least reduce) direct access by to the database by your staff to solve problems or export/import data. The less people in the database, undercutting the application the better!

·        PowerShell commands can conform to your applications business logic, making sure you don’t orphan any data or rows, or delete something that should not able to be deleted!

·        It allows for your staff to think outside of the box and develop solution and innovate around your product

Access to the PowerShell environment should be controlled via authorisation, via a flag contained within the license options – Don’t leave this open to everyone!

Reasons why (Customers)

·        Allows your customers to get the raw data from your application they need, in a format they need

·        Provide another way for them to interact with your application

·        Innovation with the data they have which can be folded back into the application via great customer relationships

There are some reasons why you would not go down this path, I wanted to point some of them.

Reasons why not:

·        Security - Another vector you need to secure and monitor

o  Migration: If you handle your authentication, authorisation and licensing correctly, this can be as secure as your application

·        Can allow large amounts of raw data transfer / bandwidth saturation

o  Mitigation: Impose thresholds and limits on the data a customer can consume – Possibly depending on which license level they purchase

·        Data transfer can be expensive

o  Mitigation: Impose thresholds and limits on the data a customer can consume – Possibly depending on which license level they purchase

·        Who knows what the scripts are doing?

o  Migration Having an audit trail of what actions a customer performed is key – either via your web application and/or the PowerShell interface, an audit trail is vital!

·        Maintenance of the code base for the PowerShell interface

o  Mitigation: If your application is .NET based, then the reskilling level needed is very small as PowerShell commands are developed in .NET and will integrate with your existing codebase, conforming to your existing business logic. If it is not a .NET based application, outsourcing may be an option for maintenance of the feature.

Take a semi-recent project I worked on which is a cloud-based product where I implemented a series of PowerShell commends.

A customer could connect to the cloud-based application, obtain a list of their stores, sales, costs, products and users/operators.

With this, the customer could great some great raw data and perform their own reporting.

This is where relationships with your clients help a great deal – If they are exporting data on a regular basis for a report they are running – Why not make that report built into your own product?

Helpdesk/support could, create stores, users/operators, perform importing and exporting of data as well as various other helpdesk/support tasks, such as performing correcting actions.

This allowed them to create some automation and deployment scripts, no longer was there a length web based processed, but a quick, repeatable and scriptable method of onboarding new customers and stores!

In Summary

Having a PowerShell interface that your staff can utilise can help drive innovation and increase efficiencies, while at the same time, allowing your power customers another benefit of your fantastic application!

Customers can help drive the next innovation wave of the product by creating their own reports and dashboards and folding them back into the application via great customer relationships.

If you want to learn more or explore the idea, feel free to get in contact with me.