EmpowerID's No Code Flows, or Business Request Flows, are designed to equip administrators with a user-friendly model for managing complex business processes. These could range from onboarding new staff, overseeing department transitions, or processing employee departures. Such tasks often involve a precise sequence of steps that can be laborious to monitor and schedule within specific time periods. Traditional workflows, while While useful for bulk processing, traditional workflows may not provide the level of detail required for these multifaceted operations. This is where No Code Flows excel, offering a comprehensive framework for managing such activities while eliminating the need for coding for administrators.
The traditional approach to creating new workflows can be both time-consuming and resource-intensive. Additionally, the absence of a continuation feature in the event of workflow interruption can result in process inefficiencies. No Code Flows have addressed address these issues by providing a streamlined method for executing intricate business processes without the necessity for coding, thereby enhancing operational efficiency.
Components of No Code Flows
...
Flow Items form the crux of the EmpowerID's No Code Flows feature, representing specific tasks or actions to be performed within a Flow Definition. They are the individual steps triggered by a Flow Event, and each one is designed to handle a particular facet of the event response. In the example of a "Person Leaver" Flow Definition, these tasks could include actions like "Remove this person from all groups" and "Disable all accounts belonging to this person."
Flow Items contain several parameters that together form a directive for the system. These parameters define the specific action to be performed, the target, and the scope of resources it should affect.
...
Alongside the Item Type Action, each Flow Item also possesses an Item Scope Type. This parameter determines the range within which the Item Type Action will execute. For example, “All Non-RBAC Group Accounts for Person” could be an Item Scope Type. This suggests that the “Bulk Remove Person Group Membership” action would apply to all group accounts associated with a person that are not managed by Role-Based Access Control (RBAC).
...
In addition to Item Type Action and Item Scope Type, Flow Items also incorporate an Item Collection Query. This parameter is an SQL statement that the system executes against specific resource types to gather a set of resources related to the Flow Item and the Item Scope Type. For example, within a Flow Item labeled "Disable All Person Accounts" with an Item Scope Type of "All Accounts for Person," the query retrieves all user accounts owned by the individual who is the subject of the Flow Item.
In effect, the Flow Item, the Item Type Action, the Item Scope Type, and Item Collection Query collectively form an instruction for the system. They define what action to take, where to apply that actionit, and the scope of resources it should impact. By stringing together multiple Flow Items within a Flow Definition, administrators Administrators can construct complex, automated workflows that respond effectively to various Flow Events by stringing together multiple Flow Items within a Flow Definition.
Flow Events
Flow Events are pivotal to EmpowerID's No Code Flows feature, acting as triggers that initiate pre-defined sequences of actions (Flow Definitions) governed by certain rules (Flow Policies). They signify specific incidents or conditions within an organization's environment, prompting a systematic response to effectively manage business processes. When an event is triggered, it is sent to the Flow Event Inbox, which is a queue-like structure that holds the events before they are processed by the system processes them.
Examples of Flow Events might include “MailboxDiscovered,” “AccountTakeover,” or “PersonLeaver.” Each one represents a unique scenario that requires specific actions.
...
The “AccountTakeover” event is a critical security-related trigger. This event could signify a potential unauthorized access or control over an account. On detecting To detect this event, the No Code Flow may involve actions such as suspending the account, notifying security teams, initiating an investigation, or implementing additional security measures. The corresponding Flow Policy would govern the specifics of these reactions.
...
The “PersonLeaver” event is triggered when an individual, such as an employee or a contractor, leaves the organization. In response to this event, a No Code Flow might involve actions like disabling the person's account, removing them from groups, archiving their emails, or revoking access to company resources. Again, a corresponding Flow Policy would dictate the sequence and conditions under which these actions should be executed.
...
Flow Policies essentially constitute the rule set of No Code Flows. They define which Flow Definitions (i.e., the sequence of Flow Items) should be triggered based on the occurrence of particular Flow Events. The policies allow for multiple rules to be defined for the same event, thereby providing a high degree of flexibility and responsiveness to dynamic organizational needs.
For example, an organization might have different procedures for when an internal employee leaves versus when an external consultant's contract ends. A Flow Policy can be set up for 'internal “internal leavers',” which triggers a specific set of Flow Items, like disabling access to certain internal systems. A , while a different policy could be set for 'external “external leavers', which might include steps to revoke ” which could trigger another set of Flow Items, like revoking temporary access rights.
...
Customizable to Your Organization's Needs
...
These are the individual tasks or actions that need to be executed as part of a Business Request. They are generated based on the flow definition, and each holds data related to the request, such as request data, assignee ID, and resource ID. Each item is processed independently , in the order defined in the flow. Items at the beginning of the flow are executed first. If an item depends on the completion of another item, it will not be executed until the dependent item is completed.
...
If the Business Request is linked to an Approval Flow policiespolicy, the request routes for approval based on the assigned Approval Flow policies.
...
Fulfillment Workflows
Fulfillment workflows define the process that occurs when a request item is approved or rejected. For approval, the workflow specifies how to execute the associated action. For rejection, the workflow defines the process that should occur.
...
The flow initiates with an event, such as “Person Mover.” This event is associated with a resource like a “Person.”
The event is added to the Event Inbox.
The applicable policies determine the flows that need to be run. These flows are then added to the Flow Inbox.
Once in the Flow Inbox, each flow awaits processing.
Upon processing, each flow creates a Business Request. This Request consists of multiple Business Request Items, which are individual tasks to be performed.
Each Business Request Item represents an action to be performed. This could range from adding the resource to a group to disabling the resource.
The sequence and timing of the Business Request Items are managed through the Flow Definition.
Upon completion, each Business Request Item will be is sent to the Business Request Fulfillment engine, which will execute executes the tasks.
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|