This article is part of a continuing series on App Portal. This week we will talk about workflows within App Portal.
Workflows control how application requests are routed. Workflows can be set up to automatically approve an application, have an application request be approved by a manager, or have a request go through a purchase process, just to name a few possibilities.
Dynamic vs. Static Workflows
Workflow steps can either be dynamic or static. You can have a combination of both in one workflow. Dynamic steps are dependent on conditions. If a computer is one area, for example, one thing could happen, while a computer in another area has a different thing happen. Take Visio, for example. Anyone in IT needing to draw diagrams may get automatic approval for Visio, while someone in HR, who may not need Visio, would have to have it approved.
Static steps are just the opposite. The same thing happens for everyone requesting a particular software title, no matter what department they belong too.
Conditions
Multiple workflows can be added to a catalog item. The system can evaluate which workflow to assign based on just about anything, from AD property value to existing in a particular SCCM collection.
Conditions allow you to apply completely separate workflows to the same catalog item. This can be vital in large environments with many departments and policies.
Creating a Workflow
To create a workflow, click the “New Workflow” button in the workflow node under Site Management.
General
Give your workflow a name. There are two other options to pay attention to on the General tab. First, Process Type. Linear is a vertical approval method where each approver approves the software request in accordance to the workflow.
Second, Pool allows anyone in the workflow process to approve the request. This allows the approver at the top to approve the request without it filtering through the lower levels of the workflow. With this method, everyone in the workflow process receives a notification that a request has been made.
Third, Pool within Group. This method is similar to Pool, though the request still has to go through all of the levels of the workflow. This option is the least common.
The final option to pay attention to is “Allow requester to define workflow”. This option is exactly what it says – it allows the requestor to select the workflow that is followed.
Workflow Steps
Lets move on the Workflow Steps tab. This is where we actually create the workflow. The steps here are called levels. The steps execute from top to bottom, meaning that the higher in the list, the earlier the level is used.
To add a level, click “Add New Level”. You are presented with this screen:
For this example, I am going to create a simple approval based on a group that is authorized to approve applications. For this to work, you must have a group in AD of approvers (you can also use a single user). To add the group, I select “User Approval Groups” and then click the “Add New Approver” button.
Next, we are presented the screen to select the approval group. Type in your group name, press Search, and select it from the box.
After pressing “Add Selected Item”, the group is added to our workflow as an approver. This is a static group the does not change.
Each workflow step can have its own set of conditions similar to the conditions I am getting ready to discuss. I would be careful with this, however, as these workflows can get very large and very tedious. Remember that workflows should govern your App Portal environment and not set up for one particular application (unless there is a good reason for it).
Conditions
Now we can add conditions to this workflow. I am going to use the organization’s IT department. All of the computers for my IT department are in one OU, so that is how I will assign the workflow condition. To do this, click “Add Condition” under the “Group and OU” tab.
Once I have the OU selected, I click on “Select”. This adds my OU to the workflow as a condition.
The “AD Property” tab will condition the workflow based on any AD attribute. Remember that you must be discovering that attribute for it to function properly. Next, the “Collection” tab conditions the workflow based on SCCM collection membership. Finally, catalog item conditions the workflow based on software cost. You can condition it if the software costs anything, or above a defined amount.
Applies To
The tab identifies which applications use this workflow. Since we have not added any applications yet, I will skip over this step until next week.
Simulate
Finally, we can simulate the workflow by entering a username or computer name. This will walk us through the workflow and show it to us step by step based on the user or computer.
Finally, click the Save button above the tabs to save the workflow.
Now that we have created a workflow, we are that much closer to having a functioning App Portal installation. Come back next week for more.
