Patent Publication Number: US-9838393-B2

Title: Encapsulating commands within a control wrapper for split entry or approval

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is related to a U.S. Non-Provisional application entitled “ENCAPSULATING COMMANDS WITHIN A CONTROL WRAPPER FOR MULTIPLE USER ENTRY,” filed concurrently herewith and identified by Ser. No. 14/816,236, the contents of which are hereby incorporated by reference in their entireties for all purposes. 
     FIELD 
     Aspects of the disclosure relate to computer hardware and software. In particular, one or more aspects of the disclosure generally relate to computer hardware and software for validating and approving commands, including encapsulating commands within a control wrapper. 
     BACKGROUND 
     Users in a computing system may be provided with various permissions or rights. For example, a common access mechanism is to provide a user with credentials, such as a user ID/name and a password. The user may present the user identification and/or password to receive access to a resource, or permission to read, write, or execute computer resources, such as computer files or databases. Some users, particularly users employed by an institution (such as a financial institution) may be provided with administrator or super-user access rights. These administrator or super-user access rights may provide a user with greater or more expansive abilities to perform read, write, delete, modify, and execute operations than a non-administrator user. 
     Users may be grouped together and assigned permissions based on their role within an organization or within the institution. For example, programmers may be given one set of file permissions (e.g., able to read from/write to development repositories and read-only from production repositories) which may be different from, either partially or totally, from a set of file permissions given to release engineers (e.g., able to read-only from development repositories and read-write to production repositories). Generally, access to a resource or operation of a computing device or system is viewed as a binary question: either the user has the appropriate access or permission set to access the resource or operate the computing device, or the user does not have the appropriate access or permission set, in which case the operation will be denied. 
     SUMMARY 
     Given that the very nature of their jobs may require them to have a large array of permissions, rights, access, and so on, system administrators or other user(s) having elevated permissions may be able to issue a large number of commands or instructions. In some situations, these commands may be executed without additional levels of verifications. Such access may allow an ill-intentioned or accidental change to go into a confidential file (such as a payments file, accounts file, permissions file, user database, and so on) and allow that administrative user to, intentionally or inadvertently, add, delete or change records, which may result in a security breach or loss of data integrity. 
     Logging the administrative user&#39;s access to the resource, or modification thereof, might not ameliorate the problem. For example, a malicious administrative user may be able to modify the log or prevent the logging from happening. This may reduce the likelihood the intrusion will be detected. Further, in some computing systems, internal users might not be monitored to the same degree as external users; where the presentation of a command resulting in accidental effects may take a long time to uncover. Access may be recorded and notifications may be provided, but the execution of the commands might not be prevented especially if the person is supposed to have that access. 
     Given the importance of keeping computing systems operational and accuracy in transactions, it may be useful and important for an organization and its computer systems to improve its computing devices and systems to minimize malicious or accidental execution of computing commands, prevent malicious or accidental access of sensitive data, and so on. 
     Accordingly, one or more aspects of the present disclosure provide methods that include receiving, at a computing device, an indicator of a task requiring resolution by execution of one or more commands affecting a restricted resource. The computing device may determine one or more criteria indicating that split entry of the one or more commands by a first user and a second user may be required. The first user and the second user may be users authorized to execute commands affecting the restricted resource. The computing device may transmit a first notification to a computing device associated with the first user to display information associated with the task and update a record stored at the computing device associated with the first user to include information indicating the task, and the computing device may transmit a second notification to a computing device associated with the second user to display information associated with the task and update a record stored at the computing device associated with the second user to include information indicating the task. The computing device may receive from the computing device associated with the first user, a first proposed resolution of the task comprising one or more commands affecting the restricted resource, and a second proposed resolution of the task comprising one or more commands affecting the restricted resource from the computing device associated with the second user. The computing device may compare the first proposed resolution and the second proposed resolution, and may transmit a third notification to a computing device to update a record stored at the computing device associated with the task to include information indicating a result of the comparing. 
     One or more aspects of the present disclosure may provide an apparatus which includes one or more memories. The one or more memories may store computer-readable instructions. The instructions, when executed by the processor, may cause the processor to receive an indication of a task requiring resolution by execution of one or more commands affecting a restricted resource and determine an identifier of a first user and an identifier of a second user, each of the first user and the second user authorized to execute commands affecting the restricted resource. The instructions, when executed by the processor, may cause the processor to receive, from a computing device associated with the first user, a first proposed resolution of the task comprising one or more commands affecting the restricted resource and receive, from a computing device associated with the second user, a second proposed resolution of the task comprising one or more commands affecting the restricted resource. The processor may, based on execution of the instructions generate, based on the first proposed resolution and the second proposed resolution, a unified resolution comprising one or more restricted commands. At least one restricted command of the unified resolution may be based on the first proposed resolution of the task, and at least one restricted command of the unified resolution may be based on the second proposed resolution of the task. The instructions may further cause the processor to transmit a notification to the restricted resource to update a record stored at restricted resource to include information identifying the unified resolution. 
     One or more aspects of the present disclosure may provide methods and systems for receiving, at a computing device, an indicator of a task requiring resolution by execution of one or more commands affecting a restricted resource. The computing device may determine one or more criteria indicating that split entry of the one or more commands by a first entering user and a second entering user may be required. The first entering user and the second entering user may be users authorized to execute commands affecting the restricted resource. The computing device may transmit a first notification to a computing device associated with the first entering user to display information associated with the task and update a record stored at the computing device associated with the first entering user to include information indicating the task, and may transmit a second notification to a computing device associated with the second entering user to display information associated with the task and update a record stored at the computing device associated with the second entering user to include information indicating the task. The computing device may receive, from the computing device associated with the first entering user, a first proposed resolution of the task comprising one or more commands affecting the restricted resource, and, from the computing device associated with the second entering user, a second proposed resolution of the task comprising one or more commands affecting the restricted resource. The computing device may determine that the first proposed resolution and the second proposed resolution are equivalent, and may generate a unified resolution based on the first proposed resolution and the second proposed resolution. The unified resolution may include a restricted command. The computing device may determine that split approval of the restricted command by a plurality of reviewers may be required. The plurality of reviewers may include a first reviewer and a second reviewer. The computing device may transmit a first instruction to a first reviewing computing device associated with the first reviewer to display information associated with the task and to update a record stored at the first reviewing computing device to include information indicating the task; and may transmit a second instruction to a second reviewing computing device associated with the second reviewer to display information associated with the task and to update a record stored at the second reviewing computing device to include information indicating the task. The computing device may receive, from the first reviewing computing device, a first approval status of the restricted command, and, from the second reviewing computing device, a second approval status of the restricted command. The computing device may transmit a third notification to another device to update a record stored at the another device and associated with task to include information indicating the first approval status and the second approval status. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present disclosure is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which: 
         FIG. 1  depicts an illustrative operating environment in which various aspects of the disclosure may be implemented in accordance with one or more example embodiments; 
         FIG. 2  depicts an illustrative block diagram of workstations and servers that may be used to implement the processes and functions of certain aspects of the present disclosure in accordance with one or more example embodiments; 
         FIG. 3  depicts an illustrative computing environment for analyzing threats and transmitting and receiving information to customers, agents, analysts, or the like in accordance with one or more example embodiments; 
         FIGS. 4A and 4B  depict an illustrative graphical user interface in which commands may be approved prior to their execution and/or validated after their execution, according to one or more example embodiments; 
         FIGS. 5A-D  depict graphical user interfaces illustrating approval of a command, denial of a command, and requesting of more information from an authorized user, in accordance with one or more example embodiments; 
         FIGS. 6A-C  depict graphical user interfaces illustrating co-entry of a command by multiple authorized users, in accordance with one or more example embodiments; 
         FIGS. 7A-B  depict graphical user interfaces illustrating entry of a command and a validating keycode in accordance with one or more example embodiments; 
         FIGS. 8A-B  depict illustrative properties of users and relationships between users in accordance with one or more example embodiments; and 
         FIG. 9  depicts an illustrative method of performing split entry and/or approval according to one or more example embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments in which aspects of the disclosure may be practiced. It is to be understood that other embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of the present disclosure. 
     It is noted that various connections between elements are discussed in the following description. It is noted that these connections are general and, unless specified otherwise, may be direct or indirect, wired or wireless, and that the specification is not intended to be limiting in this respect. 
       FIG. 1  depicts an illustrative operating environment in which various aspects of the present disclosure may be implemented in accordance with one or more example embodiments. Referring to  FIG. 1 , computing system environment  100  may be used according to one or more illustrative embodiments. Computing system environment  100  is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality contained in the disclosure. Computing system environment  100  should not be interpreted as having any dependency or requirement relating to any one or combination of components shown in illustrative computing system environment  100 . 
     Computing system environment  100  may include computing device  101  having processor  103  for controlling overall operation of computing device  101  and its associated components, including random-access memory (RAM)  105 , read-only memory (ROM)  107 , communications module  109 , and memory  115 . Computing device  101  may include a variety of computer readable media. Computer readable media may be any available media that may be accessed by computing device  101 , may be non-transitory, and may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, object code, data structures, program modules, or other data. Examples of computer readable media may include random access memory (RAM), read only memory (ROM), electronically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by computing device  101 . 
     Although not required, various aspects described herein may be embodied as a method, a data processing system, or as a computer-readable medium storing computer-executable instructions. For example, a computer-readable medium storing instructions to cause a processor to perform steps of a method in accordance with aspects of the disclosed embodiments is contemplated. For example, aspects of the method steps disclosed herein may be executed on a processor on computing device  101 . Such a processor may execute computer-executable instructions stored on a computer-readable medium. 
     Software may be stored within memory  115  and/or storage to provide instructions to processor  103  for enabling computing device  101  to perform various functions. For example, memory  115  may store software used by computing device  101 , such as operating system  117 , application programs  119 , and associated database  121 . Also, some or all of the computer executable instructions for computing device  101  may be embodied in hardware or firmware. Although not shown, RAM  105  may include one or more applications representing the application data stored in RAM  105  while computing device  101  is on and corresponding software applications (e.g., software tasks) are running on computing device  101 . 
     Communications module  109  may include a microphone, keypad, touch screen, and/or stylus through which a user of computing device  101  may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Computing system environment  100  may also include optical scanners (not shown). Illustrative usages include scanning and converting paper documents, e.g., correspondence, receipts, and the like, to digital files. 
     Computing device  101  may operate in a networked environment supporting connections to one or more remote computing devices, such as computing devices  141 ,  151 , and  161 . Computing devices  141 ,  151 , and  161  may be personal computing devices or servers that include any or all of the elements described above relative to computing device  101 . Computing device  161  may be a mobile device (e.g., smart phone) communicating over wireless carrier channel  171 . 
     The network connections depicted in  FIG. 1  may include local area network (LAN)  125  and wide area network (WAN)  129 , as well as other networks. When used in a LAN networking environment, computing device  101  may be connected to LAN  125  through a network interface or adapter in communications module  109 . When used in a WAN networking environment, computing device  101  may include a modem in communications module  109  or other means for establishing communications over WAN  129 , such as Internet  131  or other type of computer network. The network connections shown are illustrative and other means of establishing a communications link between the computing devices may be used. Various well-known protocols such as transmission control protocol/Internet protocol (TCP/IP), Ethernet, file transfer protocol (FTP), hypertext transfer protocol (HTTP) and the like may be used, and the system can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Any of various conventional web browsers can be used to display and manipulate data on web pages. 
     The disclosure is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the disclosed embodiments include, but are not limited to, personal computers (PCs), server computers, hand-held or laptop devices, smart phones, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. 
       FIG. 2  depicts an illustrative block diagram of workstations and servers that may be used to implement the processes and functions of certain aspects of the present disclosure in accordance with one or more example embodiments. Referring to  FIG. 2 , illustrative system  200  may be used for implementing example embodiments according to the present disclosure. As illustrated, system  200  may include one or more workstation computers  201 . Workstation  201  may be, for example, a desktop computer, a smartphone, a wireless device, a tablet computer, a laptop computer, and the like. Workstations  201  may be local or remote, and may be connected by one of communications links  202  to computer network  203  that is linked via communications link  205  to server  204 . In system  200 , server  204  may be any suitable server, processor, computer, or data processing device, or combination of the same. Server  204  may be used to process the instructions received from, and the transactions entered into by, one or more participants. 
     Computer network  203  may be any suitable computer network including the Internet, an intranet, a wide-area network (WAN), a local-area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), or any combination of any of the same. Communications links  202  and  205  may be any communications links suitable for communicating between workstations  201  and server  204 , such as network links, dial-up links, wireless links, hard-wired links, as well as network types developed in the future, and the like. 
       FIG. 3  depicts an illustrative computing environment for authoring, issuing, executing, authorizing, and validating commands associated with one or more users of a computing system, in accordance with one or more example embodiments. Referring to  FIG. 3 , computing environment  300  may include one or more computing devices, including administrator computing devices  340 ( 1 ) and  340 ( 2 ), and one or more validation user computing devices  330 , one or more governance user computing devices  360 . The devices depicted in  FIG. 3  may be present in any number in the computing environment  300 . 
     Other devices and systems, including other computing devices associated with one or more customers, agents, customer service representatives (CSRs), retail locations, executives, and so on, may be present in the computing environment  300 , but not depicted in  FIG. 3 . Additionally or alternatively, such non-depicted devices may overlap with one of the depicted devices or systems. For example, a customer computing device may be used by and/or configured to be used by a customer of an organization, such as a particular customer of a financial institution, and may be a mobile device or non-mobile device. In some aspects, a customer may have more than one customer computing device with which they interact with other computing devices and systems and components and subcomponents thereof. In some aspects, a customer computing device may be shared by one or more customers of the organization. 
     A CSR computing device may be another example of a computing device which may be present in computing environment  300  but not illustrated in  FIG. 3 . A CSR computing device may, e.g., be used by an agent of an organization, such as a customer-facing agent tasked with responding to customer requests regarding account status, information, inquiries, promotions, or the like. Such requests may be received at CSR computing device in any of a number of formats, including video messaging, text messaging, two-way messaging (e.g. instant or chat messaging), voice (e.g. by way of a telephone, VoIP, or other like voice-carrying formats), e-mail, or the like. Such customer requests or messages may be received at the CSR computing device from customer computing device via a public network individually or in conjunction with an organization network. In some aspects, the CSR computing device also may include a terminal device (which may, e.g., be used by a local agent of an organization in a retail location of the organization, such as by a bank teller of a financial institution who is located in a banking center of the financial institution). 
     Administrator computing devices  340 ( 1 ) and  340 ( 2 ) may each be used by one or more administrators or other authorized users (e.g., super-users) associated with an organization or institution. These computing devices may be specially programmed to enable administrators or authorized users to read, write, execute, access, and modify resources, or perform other similar operations. Each of computing devices  340 ( 1 ) and  340 ( 2 ) may include peripherals, accessories, components, sub-components, hardware, software, firmware, and so on which may enable an administrator or user operating the computing devices  340 ( 1 ) and  340 ( 2 ) to receive and/or transmit a variety of data. These accessories or components may include, for example, components such as a video camera and/or microphone, which may be used in combination to facilitate messaging such as video messaging, text-messaging, voice messaging, two-way messaging, and so on. Computing devices  340 ( 1 ) and  340 ( 2 ) may be configured to receive inputs from an authorized user and/or administrator via a variety of input-enabling components (e.g., video camera, keyboard, mouse, microphone, touchscreen, and so on). These inputs may include instantiating an attempt to access a resource, commands to be executed by one or more resources and/or computing devices, or other input which may require approval. In some aspects, the user may be authorized via a permission, credential, token, password, or the like to access the resource. For example, a user may be provided with an administrator password which facilitates access to a resource. As another example, a user may be assigned a role of administrator. A computing device or component of a computing device present in the computing environment  300  may include a permissioning resource or service which may establish that users assigned the role of administrator may have access to a resource. As another example, a user may present a credential or token (e.g., biometric, authentication code, or the like) which may identify the user as an administrator or other authorized user. 
     Governance user computing device  360  may be used by a user of an organization tasked with reviewing and approving commands inputted by authorized users (e.g., users operating administrator computing devices  340 ( 1 ) and/or  340 ( 2 )). Governance user computing devices may include peripherals, accessories, components, sub-components, hardware, software, firmware, and so on which may enable a governance user operating the governance user computing device  360  to receive and/or transmit a variety of data. These accessories or components may include, for example, components such as a video camera and/or microphone, which may be used in combination to facilitate messaging such as video messaging, text-messaging, voice messaging, two-way messaging, and so on. In some aspects, these accessories or components may facilitate a connection to request information from one or more users operating administrator computing devices  340 ( 1 ) and/or  340 ( 2 ). This connection may include a communication transmitted via organization network  370 . 
     Governance user computing device  360  may be configured to receive inputs from an governance user via a variety of input-enabling components (e.g., video camera, keyboard, mouse, microphone, touchscreen, and so on). In some aspects, a governance user may be also an administrator, and as such, governance user computing device  360  may include any or all of the above-discussed components of administrator computing device  340 ( 1 ) and/or  340 ( 2 ). 
     Computing environment  300  also may include a validation user computing device  330 . As with governance user computing device  360 , validation user computing device  330  may be used by a user of an organization tasked with reviewing and approving commands inputted by authorized users (e.g., users operating administrator computing devices  340 ( 1 ) and/or  340 ( 2 )). 
     In some aspects, a governance user may be tasked with approving commands prior to their execution, and a validation user may be tasked with approving commands after their execution. For example, an administrator may input a command or group of commands. With reference to  FIG. 4A  and  FIG. 4B , which will be discussed further below, an administrative user may input command  403 , command  404 , command  413 , and command  414 . As depicted in  FIG. 4A , command  403  and command  404  may be, subsequent to their input by the administrative user, held as pending commands for approval by a governance user (indicated by reviewer name  401  and pending commands tab  402 ). As depicted in  FIG. 4B , command  413  and  414  may be issued commands, the result of which may need to be validated by a validation user (indicated by reviewer name  411  and issued commands tab  412 ). 
     Returning to  FIG. 3 , a validation user may be also an administrator, and as such, validation user computing device  330  may include any or all of the above-discussed components of administrator computing device  340 ( 1 ) and/or  340 ( 2 ). Additionally, the roles of validation user and governance user may overlap, and one or more devices may include the components of validation user computing device  330  and governance user computing device  360 . Validation user computing devices may include peripherals, accessories, components, sub-components, hardware, software, firmware, and so on which may enable a governance user operating the validation user computing device  330  to receive and/or transmit a variety of data. These accessories or components may include, for example, components such as a video camera and/or microphone, which may be used in combination to facilitate messaging such as video messaging, text-messaging, voice messaging, two-way messaging, and so on. In some aspects, these accessories or components may facilitate a connection to request information from one or more users operating administrator computing devices  340 ( 1 ) and/or  340 ( 2 ). This connection may include a communication transmitted via organization network  370 . 
     As noted above, and as illustrated in greater detail below, any and/or all of the computing devices and computing platforms of computing environment  300  may be special-purpose computing devices configured to perform specific functions. 
     Computing environment  300  also may include one or more computing platforms. For example, computing environment  300  may include a computing platform  310 . The computing platform  310  may include one or more special-purpose or specially-programmed computing devices configured to perform one or more of the functions described herein. For example, the computing platform  310  may include one or more computers (e.g., laptop computers, desktop computers, servers, server blades, or the like). Computing platform  310  may include one or more processors  311 , memory  312 , and communication interface  316 . A data bus may interconnect processor(s)  311 , memory  312 , and communication interface  316 . Communication interface  316  may be a network interface configured to support communication between computing platform  310  and organization network  370  and/or one or more sub-networks thereof. Memory  312  may include one or more program modules having instructions that when executed by processor(s)  311  cause computing platform  310  to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s)  311 . 
     For example, memory  312  may include a wrapper module  313 , which may include instructions that when executed by processor(s)  311  cause computing platform  310  to perform one or more functions described herein, such as instructions for encapsulating one or more commands with a command wrapper. Execution of the command wrapper may, for example, queue the encapsulated command for approval by a governance user, co-entry by multiple administrative users, and/or validation after execution by a validation user. For instance, wrapper module  313  may include executable instructions for and/or otherwise provide a wrapping engine  314 , which may be used in generating and/or applying one or more command wrappers to commands. 
     In addition, memory  312  may include a command database  315 , which may store information identifying one or more generated or applied command wrappers, and/or commands which, when executed, require encapsulation with a command wrapper, and/or information associated with or identifying data retrieved based on one or more commands or encapsulated commands, as illustrated in greater detail below. Commands for which information may be stored in command database  315  may include, for example, various operating system commands, application commands, user interface commands, database commands, network commands, and so on. 
     Computing environment  300  also may include one or more networks, which may interconnect one or more of the computing devices and/or platforms. For example, computing platform  310 , administrator computing devices  340 ( 1 ) and  340 ( 2 ), governance user computing device  360 , and validation user computing device  330  may be interconnected via organization network  370 . Organization network  370  may include one or more sub-networks (e.g., LANs, WANs, VPNs or the like). Organization network  370  may be associated with a particular organization (e.g., a corporation, financial institution, educational institution, governmental institution, or the like) and may interconnect one or more computing devices associated with the organization. For example, computing platform  310 , administrator computing devices  340 ( 1 ) and  340 ( 2 ), governance user computing device  360 , and validation user computing device  330  may be associated with an organization (e.g., a financial institution), and organization network  370  may be associated with and/or operated by the organization. 
     A public network may be present in computing environment  300 , although not illustrated in  FIG. 3 . A public network may connect an organization network (e.g., organization network  370 ) and/or one or more computing devices connected thereto (e.g., computing platform  310 , administrator computing devices  340 ( 1 ) and  340 ( 2 ), governance user computing device  360 , and validation user computing device  330 ) with one or more networks and/or computing devices that are not associated with the organization. For example, other computing devices (e.g., credentialing services, third-party authenticator services, or the like) may be owned and/or operated by one or more entities different from the organization that operates organization network  370 , rather than being owned and/or operated by the organization itself or an employee or affiliate of the organization), and the public network may include one or more networks (e.g., the internet) that connect those computing devices not operated by the organization to organization network  370  and/or one or more computing devices connected thereto (e.g., computing platform  310 , administrator computing devices  340 ( 1 ) and  340 ( 2 ), governance user computing device  360 , and validation user computing device  330 ). 
       FIG. 4A-4B  depict an illustrative user interface for approving commands prior to execution and validating commands subsequent to execution, in accordance with one or more aspects of the present disclosure. As discussed above, an organization may employ one or more users who may be provided with access to restricted resources. These restricted resources may include databases or other data-storing devices or platforms, which may store financial information, user information, transaction information, account information, medical record information, or other sensitive data. Additionally or alternatively, these restricted resources may include systems or devices which may operate in a production environment, where sensitive data is received and processed. Additionally or alternatively, these restricted resources may include systems or devices which may operate in a non-production environment, such as a development environment, testing environment, staging environment, quality assurance environment, and so on. For example, a non-production environment may be provided so that authorized users may prepare modules, code, software, hardware, and so on for eventual deployment to a production environment. 
     In some aspects, the development environment might not include sensitive data, but access may be restricted to prevent accidental or malicious deletion of modules in-development. Access may also be restricted to prevent insertion of accidental code (e.g., a “software bug”) or malicious data or instructions which, if propagated to the production environment, may result in a security breach. In some aspects, a non-production environment may be used to diagnose problems with sensitive data, and as such, access to the non-production environment may be restricted to comply with internal or external security rules, regulations, laws, statutes, and so on. In some aspects, the users provided access to these restricted resources may be administrators, super-users, authorized users, and so on. 
     In some aspects, to prevent or eliminate accidental or ill-intentioned usage of the restricted resources by the users granted access (e.g., the authorized users), an organization may employ one or more users tasked with pre-execution approval, co-entry, or post-entry validation of commands entered by authorized users. In some aspects, a governance user may be tasked with approving commands prior to their execution, and a validation user may be tasked with approving commands after their execution. For example, an authorized user may input a command or group of commands and queue them for execution on a computing device and/or platform. With reference to  FIG. 4A , a user interface  400  may be instantiated on a computing device associated with a governance user (e.g., governance user computing device  360 ). In some aspects, a governance user may be notified to access user interface  400  via one or more notification mechanisms. For example, the governance user may be sent an e-mail indicating a command has been queued for pre-execution approval. As another example, a mobile device (e.g., smartphone, tablet device, or so on) associated with the governance user may receive a signal indicating that a notification should be presented to the governance user informing them of the queuing of a command for pre-execution approval. 
     As illustrated in  FIG. 4A , screen  410  may contain an indication of an authorized user  408  who has entered one or more commands  403  and  404  for execution. A computing device and/or computing platform (e.g. administrator computing device  340 ( 1 ), administrator computing device  340 ( 2 ), governance user computing device  360 , computing platform  310 ) may detect the entry of commands  403  and  404 . 
     As an example of such detection by one or more computing devices and/or computing platforms, consider the “DELETE credit_card_transaction FROM FILE first.test ON devDB” command  403 . The “DELETE” command (e.g., the portion of a computing program or package providing the computer instructions and/or operative functionality to delete) may be encapsulated with a control wrapper by, for example, wrapper module  313  and/or wrapping engine  314 . As such, the computing device and/or computing platforms executing the entered commands may, upon encountering the encapsulated DELETE command, queue the instruction (or a sequence of instructions including the DELETE command) for pre-execution approval by a governance user. The computing device and/or computing platform may determine that a sequence of commands may need to be held for execution prior to the execution of any command in the sequence. For example, the DELETE command may have been entered as part of an atomic transaction (e.g., an indivisible transaction) and other commands of the atomic transaction may also need to be held to prevent atomicity failures. 
     Within screen  410 , a governance user may be presented with an approval input control  405 , a request information input control  406 , and a denial input control  407 . In some aspects, input of a determination of the governance user may be via different input mechanisms, controls, or devices than the buttons illustrated in screen  410 . For example, a governance user may provide as input the spoken words “approve,” “request,” and/or “deny” which may be received via a microphone and processed accordingly. The governance user may review one or more of the commands  403  and  404  and select the appropriate input. For example, the governance user may determine that the DELETE command  403  is approvable because it may result in a desired deletion of a test file on a development database. The governance user may select the command  403  and input an indication of approval by the governance user (e.g., select approval input control  405 ). Alternatively, the governance user may determine that the DELETE command  403  is not approvable because it may result in a non-desirous deletion of a test file on a development database (for example, because the file is associated with a user different from the authorized user who entered the command). The governance user may indicate denial of the command (e.g. select denial input control  406 ), and an appropriate indication may be returned to the computing device and/or computing platform executing the commands. An indication of the denial may also be transmitted to a computing device associated with the authorized user that originally input the command (e.g., the device where the commands were entered, another device, or the like). For example, the authorized user that input the DELETE command may receive an e-mail indicating that the command has been denied. 
     Additionally or alternatively, and with reference to  FIG. 4B , a user interface  400  may be instantiated on a computing device associated with a validation user (e.g., validation user computing device  360 ). In some aspects, a validation user may be notified to access user interface  400  via one or more notification mechanisms. For example, the validation user may be sent an e-mail indicating a command has been queued for post-execution validation. As another example, a mobile device (e.g., smartphone, tablet device, or so on) associated with the validation user may receive a signal indicating that a notification should be presented to the validation user informing them of the queuing of a command for post-execution validation. 
     As illustrated in  FIG. 4B , screen  410  may contain an indication of an authorized user  411  who has entered one or more commands  413  and  414 , which may have already been executed. A computing device and/or computing platform (e.g. administrator computing device  340 ( 1 ), administrator computing device  340 ( 2 ), validation user computing device  330 , computing platform  310 ) may detect the entry of commands  413  and  414 . 
     As an example of such detection by one or more computing devices and/or computing platforms, consider the “WRITE credit_card_transaction TO FILE first.test ON devDB” command  413 . The “WRITE” command (e.g., the portion of a computing program or package providing the computer instructions and/or operative functionality to write) may be encapsulated with a control wrapper by, for example, wrapper module  313  and/or wrapping engine  314 . As such, the computing device and/or computing platforms executing the entered commands may, upon encountering the encapsulated WRITE command, queue the instruction (or a sequence of instructions including the WRITE command) for post-execution validation by a validation user. The computing device and/or computing platform may determine that a sequence of commands may need to be flagged as associated with the queued command in case the executed command is not approved. For example, the WRITE command may have been entered as part of an atomic transaction (e.g., an indivisible transaction) and other commands of the atomic transaction may need to be undone and/or rolled back to prevent atomicity failures. 
     Within screen  410  and/or screen  420 , a validation user may be presented an approval input control, a request information input control, and/or a denial input control, as discussed above. In some aspects, the input controls may be different than the buttons illustrated in screens  410  or  420 , or an indication of the determination by the validation user may be input via another mechanism, component, or device. For example, a validation user may provide as input the spoken words “approve,” “request,” and/or “deny” which may be received via a microphone and processed accordingly. The validation user may review one or more of the commands  413  and  414  and select the appropriate input. For example, the validation user may determine that the WRITE command  413  is approvable because it resulted in a desired deletion of a test file on a development database. The validation user may select the command  413  and input an indication of approval by the governance user (e.g., select approval input control  405 ). Alternatively, the governance user may determine that the WRITE command  413  is not approvable because it may result in a non-desirous deletion of a test file on a development database (for example, because the file is associated with a user different from the authorized user who entered the command). The validation user may indicate denial of the command (e.g. select denial input control  406 ), and an appropriate indication may be returned to the computing device and/or computing platform executing the commands. An indication of the denial may also be transmitted to a computing device associated with the authorized user that originally input the command (e.g., the device where the commands were entered, another device, or the like). For example, the authorized user that input the WRITE command may receive an e-mail indicating that the command has been denied. 
     The computing device/computing platform executing the commands may be different from the computing device and/or computing platform where pre-execution approval, or post-execution validation, occurred and different from the computing platform or computing device where the commands were input or entered. For example, the computing platform  310  may execute the commands entered at administrator computing device  340 ( 1 ). 
     The computing platform  310  may determine that one or more commands entered at administrator computing device  340 ( 1 ) require pre-execution approval. Where the command is presented for pre-execution approval, the computing platform  310  may communicate an indication of the command to the governance user computing device  360  for pre-execution approval and may pause, halt, wait, terminate, or delay execution of the command (or a sequence of commands). The computing platform  310  may receive an indication of approval of the command and may resume, restart, begin, commence, start, or execute the command (or sequence of commands). The command may be any type of command, such as an operating system command, application command, user interface command, database command, network command, and so on. 
     Additionally or alternatively, the computing platform  310  may determine that one or more commands entered at administrator computing device  340 ( 1 ) require post-execution validation. Where the command is flagged for post-execution validation, the computing platform  310  may communicate an indication of the command to the validation user computing device  330  for post-execution validation and may flag, identify, associate, mark, the command or the result of execution of the command (or a sequence of commands). The computing platform  310  may receive an indication of approval of the command and may remove the flag or other marker. Alternatively, the computing platform may receive an indication of denial of the command and may undo, remove, roll back, or wipe the execution of the command or the result of the execution of the command (or sequence of commands). The command may be any type of command, such as an operating system command, application command, user interface command, database command, network command, and so on. 
     Criteria which may be used in determining whether one or more commands entered require pre-execution approval or post-execution validation include, for example, information about the entered command (e.g., “move,” “delete,” and so on), information about the variables entered with the entered command (e.g., “delete one row,” “delete all rows,” “add $X.XX to account Z,” “add $YYYYYY.YY to account ZA,” and so on), or information about the user requesting execution of the command (e.g., userID, role, account status, login time, last verified location, number of demerits, or the like). Other examples of criteria may be information about the computing device operated by the user requesting execution of the command such as Internet Protocol address, Media Access Control address, network connection status, running process information, geographical location of the device, device type (e.g., smartphone, server, tablet, laptop, desktop, and so on). Further examples of criteria may be information about the restricted resource, device platform, system, and/or environment the authorized user is attempting to access (e.g., a database, a server, a production device, a test repository, computing platform  310 , and so on). Still further examples of criteria may be contextual information, such as time of day, a case number, issue number, tracking number or other data provided with the inputted command to indicate the command is genuine, authentic, or so on. The criteria information may be supplied by the authorized user as part of a command entry process or determined at and/or provided by the device at which the command was entered, or another device, system, platform, or the like (e.g., computing platform  310 ). 
       FIGS. 8A and 8B  illustrate still further examples of various criteria which may be used in performing a determination that a pre-execution approval or post-execution validation is required. One illustrative criteria may be whether an authorized user has been pre-approved to execute the inputted command: if the user is pre-approved to execute the command, approval by another user prior to execution (e.g., by a governance user) or subsequent to execution (e.g., by a validation user) might not be required.  FIG. 8  provides an illustrative computing system for purposes of discussion of such pre-approval. 
     In the illustrative computing system  800 , in addition to the data collection  820  which may store information about the authorized users of the computing system two databases may be present: a development database (dev DB) and a production database (prod DB). Furthermore, authorized users may have access to only seven commands when interacting with the illustrative development database and illustrative production database: read a row (“read”), append a new row to the database (“write”), copy an existing row to a new row (“copy”), flag a row for review (“flag”), delete a row from the database (“delete”), modify an existing row (“modify”), and move a row from one database to the other database (“move”). Of course, this scenario is presented only for discussion purposes, and in other embodiments of the present disclosure, any number and type of commands may be used, as the users may interact with any number or type of computing devices and/or computing platforms. Assume that User 1  ( 802 ) may be a developer within an organization, which may be indicated by an appropriate field within the data collection (e.g., the “role” field). User  802  may receive, as a result of their role as developer, authorization to access the production database and the development database. 
     In some aspects, an authorized user may receive pre-approval status with respect to one or more commands, resources, computing devices, computing platforms, computing systems, and/or computing environments. For example, User  802  may be pre-approved to enter the “read,” “write,” “copy,” and “flag” commands on the development database, because the user&#39;s pre-approval code of “1” may indicate development database pre-approval only, and/or because the enumerated pre-approved commands may be indicated as “read, write, copy, flag.” As another example, a user named User 4  ( 804 ), who may be an database architect, may be pre-approved to read, write, flag, and modify on the production database and/or the development database. The pre-approval may be provided on a command basis (e.g., the fourth column of data collection  800 ) and/or on a device basis, resource basis, platform basis, system basis, and/or environment basis (e.g., the third column of data collection  800 ). In some aspects, pre-approval with respect to operating a device, resource, platform, and so on may provide rights to access additional devices, resources, platforms, and so on. For example, pre-approval may be provided to commands for operating a database, and based on the pre-approval to operate the database, pre-approval may also be provided to access a network resource (e.g., server, router, hub, or the like) to facilitate communication with the database. In some aspects, as depicted in  FIG. 8A , information regarding pre-approval of a resource, system, platform, and so on may be stored as a single bit (e.g., a first bit in the third column of data collection  800  indicates whether the user is pre-approved for the development database, and a second bit in the same column indicates whether the user is pre-approved for the production database). 
     More complex forms of indicating pre-approval status than that depicted in  FIG. 8A  are possible and within the scope of the present disclosure. For example, a user may be pre-approved to execute a first set of commands for a first resource (e.g., a production database) and a second set of commands for a second resource (e.g., a development database). Another example may be that a user is pre-approved for a command where a variable to the command is within a predetermined range and/or above or below a certain threshold. For example, a user may be pre-approved to perform a “write” command when a variable (e.g., “payment amount”) is below a certain threshold (e.g., “$XXX.XX USD”). 
     In some aspects, a criteria for performing a determination as to whether approval of a command may be whether a user is forbidden from executing a command. A prohibition may prevent a user&#39;s execution of the command from ever being approved (e.g., pre-approved, approved prior to execution, and/or validated subsequent to execution). For example, returning to the illustrative data collection  800  depicted in  FIG. 8A , User  802  may be forbidden from invoking the “delete” command. As with pre-approval, a prohibition may be provided on a command basis (e.g., the fifth column of data collection  800 ) and/or on a device basis, resource basis, platform basis, system basis, and/or environment basis. 
     In some aspects, an organization may employ one or more governance users and/or one or more validation users who have been trained to review commands. These governance users and/or validation users may receive commands as they are inputted and queued for execution, or executed and queued for validation. In some aspects, this might not be with regard to the authorized user who input the command (e.g., a common queue of inputted or executed commands may be worked by one or more governance users or one or more validation users in the order of execution). 
     As illustrated by  FIG. 8B , governance users and/or validation users may be assigned individual authorized users or roles, or individual commands (or groups of commands). For example, User 5  and User 3  may be tasked with reviewing any User 1  attempt to execute a “write” command on the production database resource. In some aspects, both User 5  and User 3  must approve the attempt for the execution to commence. As another example, User 3  or User 4  may be tasked with reviewing any attempt by User 2  to invoke the modify command on the production database. In some aspects, only one of User 3  and User 4  need approve the command (e.g., the command is queued for approval in either a queue for User 3  or a queue for User 4 , but might not be queued in both queues). In some aspects, multiple levels of review may be desired. For example, after one of User 3  and User 4  approve the command, the command may be sent to User 6  for that user&#39;s further review. If the reviewing user at the first level denies the command (e.g., the user selected between User 3  and User 4  denies the command), the denial may be sent to User 6  for review of the denial. 
     Note that, in some aspects, a reviewing user might not have permissions or authorization to execute or invoke the command. An example use case may be, for example, when a governance user or validation user is a non-technical user tasked with reviewing execution of commands for legal or regulatory compliance. For example, any attempt to modify a production database may need be reviewed by a governance user. The hierarchy and rules regarding pre-execution approval or post-execution validation may be predefined, ordered (e.g., first applied rules may trump later applied rules), user-specified, or determined by one or more computing devices of the present disclosure by analysis of various governance user trends or workflows, and so on. For example, computing platform  310  and/or governance user computing device  360  may be programmed to determine that a particular governance user is qualified to review execution of a command. This qualification may result from, for example, an indication that the governance user has received training in the command, has recently reviewed a previous execution of the command, or so on. 
       FIGS. 5A-5D  depict illustrative graphical user interfaces resulting from inputs of the governance user and/or the validation user on screens  410  and  420 .  FIG. 5A  depicts a denial screen  500  which may result from a governance user or validation user inputting a denial of a command, either prior to execution of the command or subsequent to its execution. For example, screen  500  may be presented to a governance user if the governance user operates the denial input control  407 . A confirmation of the denial  502  may be presented, as well as an input control  503  wherein the governance user and/or the validation user may provide an explanation as to why the command was denied. This may be recorded and stored at a data storage device for further analysis and review. 
       FIG. 5B  depicts an approval screen  510  which may result from a governance user or validation user inputting an approval of a command, either prior to execution of the command or subsequent to its execution. For example, screen  510  may be presented to a validation user if the validation user operates the approval input control  405 . A confirmation of the approval  512  may be presented, as well as an input control  513  wherein the governance user and/or the validation user may provide an explanation as to why the command was approved. This may be recorded and stored at a data storage device for further analysis and review. 
       FIGS. 5C and 5D  illustrate user interfaces for a governance user and/or a validation user to request more information from an authorized user prior to the denial or approval of commands under review. More information from the authorized user may be desirable in situations, such as (for example) where the command is complicated, affects a certain resource or device, or is difficult for the governance user or validation user to understand. Upon inputting that more information is requested from the authorized user who input the command (e.g., upon selection of information input control  406 ), a governance user or validation user may be provided with one or more selections to request additional information. The selections may be as illustrated in  FIG. 5C , and may include (for example), video selection control  522 , audio selection control  523 , text message selection control  524 , and e-mail selection control  525 . The various options present or selectable by a governance user or validation user in screen  520  (e.g., via tab  521 ) may be determined by available software, firmware, hardware, and so on at one or more computing devices. For example, audio selection control  523  may be unselectable because it may be determined that a telephone of an authorized user is non-operational. 
     A governance user or validation user may select one or more of the selection controls  521 - 524 , and therefore select its corresponding mechanism to contact the authorized user. In some aspects, a selection may be made from the available choices for the requesting user by a computing device or platform. In some aspects, the computer-selected information request mechanism may be selected based on the one or more criteria discussed above (e.g., a command may be associated with a high-severity issue, and resolution of the high-severity issue may be achieved more rapidly if the authorized user and the governance user communicate in real-time, such as via video or audio). 
     Once a selection has been made, as illustrated in  FIG. 5D , a communication mechanism may be instantiated. For example, where a video communication is requested, a video service provider (either operated by the organization or a third party) may be contacted and video services may be requested. The video service provider may contact one or more devices associated with the authorized user (e.g., administrator computing device  340 ( 1 ), a mobile device associated with the authorized user). If audio services are requested, a service providing audio communication between the users may be instantiated (e.g., telephone call via POTS, ISDN, VoIP, Internet call, and so on). Multiple selections may be made from screen  520  in situations, for example, where information is urgently needed by the reviewing user to approve or deny execution of the command. Once the information is received (via video, audio, and/or other communication service or system), the reviewing user (e.g., governance user or validation user) may approve or deny the command by selecting approval input control  536  or denial input control  535 , which operate in a similar manner to the respective input controls discussed with respect to  FIGS. 4A and 4B . 
       FIGS. 6A-6C  illustrate example user interfaces in accordance with a split entry or co-entry command process, in accordance with one or more aspects of the present disclosure. In some aspects, in addition to or in the alternative from the pre-approval and/or post-execution validation, one or more commands may be co-entered by one or more authorized users. A first authorized user having a set of permissions including access to a restricted resource or device may be assigned a task, issue, case, or the like. The first authorized user may enter one or more commands to satisfy the task requirements, correct the issue, resolve the case, or so on. A second authorized user, who may have a different set of permissions may also be assigned the same task, issue, case, or the like. In some aspects, the first and second authorized user might not be aware of each other. For example, the first authorized user might not be aware of the identity, location, presence, or role of the second authorized user. Each of the first authorized user and the second authorized user might not be aware that both users have been assigned the same task, issue, case, or so on. 
     As illustrated in  FIG. 6A , screen  600  may contain window  601  for providing instruction. An authorized user (e.g., the first authorized user or the second authorized user) may be provided with case information  602  and/or issue information  603 . The case information  602  and/or issue information  603  may assist the authorized user in diagnosing the issue or case and in formulating commands for entry. Once formulated, the commands may be entered in command input control  604  for submission using submit input control  605 . 
     In some aspects, screen  600  or components thereof may be displayed to two authorized users simultaneously. For example, the first authorized user may be operating administrator computing device  340 ( 1 ) and the second authorized user may be operating administrator computing device  340 ( 2 ). One or more computing devices and/or computing platforms may determine the availability of both users and/or both computing devices for diagnosis of the task, issue, and entry of one or more commands. Each computing device may receive at substantially the same time a signal indicating the task (e.g., case information  602  and/or issue information  603 ) and may cause to be displayed screen  600  and/or window  601 . Simultaneous display of the command to both the first authorized user and the second authorized user may be desirable in an environment where tasks are discretized. 
     In some aspects, screen  600  might not be displayed simultaneously to both first authorized user and the second authorized user. A first user may receive the task, work the task (by diagnosing an issue or problem using informational components  602  and  603 ) and submit their resolution of the task. A computing device and/or computing platform (e.g., computing platform  310 ) may determine, based on the task, issue, command, authorized user, or other criteria, that co-entry of a resolution of the task is required. In response, the computing device and/or computing platform might not execute the entered commands (e.g., entered via command input control  604 ) but instead may transmit a signal to a second computing device and/or computing platform to display the same task, case, or issue information to a second authorized user. 
     The second authorized user may work the task (by diagnosing an issue or problem using informational components  602  and  603 ) and submit their resolution of the task. Once the second resolution of the task is received, a computing device and/or computing platform may compare the two received resolutions. This comparison may be a literal comparison, or may be based on one or more properties of the two resolutions (e.g., length of entered commands, variables entered, affected resources, and so on). Additionally or alternatively, the computing device and/or computing platform may generate a unified resolution based on the first resolution from the first authorized user and the second resolution from the second authorized user. The unified resolution may include commands from either or both of the resolutions. 
     If the two resolutions are not comparable, and/or a unified resolution cannot be generated based on the two resolutions, the result of the comparison may be presented to one or both authorized users (or to another user of the computing environment such as a supervisor, governance user, or validation user). For example, as illustrated in  FIG. 6B , identification information about both authorized users may be presented in screen  610  along with their inputted resolutions (e.g., commands or sequences of commands). In this illustrative user interface, one of the two authorized users may be tasked with reviewing the two inputted resolutions  612  and  613  and determining if zero, one, or both correctly resolves the problem. The authorized user may select one of the resolutions by using the appropriate control of  614  and/or  615 , or may request information from the other authorized user using input control  616 , which may invoke a video, audio, instant message, or e-mail communication session with the other authorized user in a manner similar to that discussed above with respect to  FIGS. 5C-D . 
     Alternatively, if the two resolutions are comparable, the result of the comparison may be presented to one or both authorized users (or to another user of the computing environment such as a supervisor, governance user, or validation user). For example, as illustrated in  FIG. 6C , both the first authorized user and the second authorized user entered the same resolution (e.g., commands or sequences of commands). In the illustrative user interface of  FIG. 6C  (e.g., screen  620  comprising comparison information  621  and command information  622 , one, both, and/or other users may be informed that the inputted commands will be queued for execution. Of course, in some aspects, a co-entered or split-entered command may be queued for pre-execution approval and/or post-execution validation. 
       FIG. 7  illustrates another mechanism for performing pre-execution approval, post-execution validation, and/or co- or split-entry of one or more commands using keycodes. The use of keycodes may serve as an additional or alternative mechanism to facilitate review of entered commands, as one or more users may be required to affirmatively input a value to indicate review of the entered command has been performed. Users of the computing environment may be provided with keycodes. A keycode may be a static passcode, password, or passphrase, but may also be dynamically generated. In some aspects, a keycode may be generated by a first computing device and/or computing platform (e.g., computing platform  310 ) and transmitted to a computing device associated with the authorized user (e.g., administrator computing device  340 ( 1 )). In some aspects, applications operating on multiple computing devices may be instantiated with the same base value, and keycodes may be generated based on application of an algorithm so that base value so that the multiple computing devices generate the same keycode in synchronous manner. 
     As illustrated in  FIG. 7A , an authorizing user may be presented with a user interface comprising a screen  700  and a window  701  for entry of one or more commands. As illustrated, in some aspects, case or issue information similar to that discussed above with respect to  FIG. 6A  may be provided. The authorized user may enter one or more commands in the command entry input control  702 . Additionally, the authorized user may enter a keycode in keycode entry input control  703 . 
     As illustrated in  FIG. 7B , a reviewing user (e.g., another authorized user, a governance user, a validation user, and so on) may be presented with a user interface including screen  710  and window  711 . This user interface may be presented on any computing device of the computing environment. The reviewing user may review the entered command or sequence of commands  712  (e.g., one or more commands queued for pre-execution approval, one or more command awaiting post-execution validation) and may provide, via keycode input control  713  the keycode of the reviewing user. In some aspects, the user interface of  FIG. 7B  may include an command input control to facilitate co-entry of one or more commands in a manner similar to that discussed above with respect to  FIGS. 6A-C . 
       FIG. 9  depicts an illustrative method of providing split entry and/or split approval of entered commands prior to execution of the commands in accordance with one or more example embodiments. In some aspects, a similar method to that depicted in  FIG. 9  may be used to provide split validation of commands subsequent to the execution of commands. At step  905 , a computing device (e.g., administrator computing device  340 ( 1 ) or  340 ( 2 ) may receive a notification of a task, issue, failure, or the like which may be resolved by entry of one or more commands executed on a computing device, computing system, or computing platform. In some aspects, these commands may include accessing of a restricted resource. At step  910 , a determination may be made as to whether split-entry of commands is required. This may include, for example, examining one or more criteria regarding the task, issue, failure, and so on (e.g., which computing device or resource is affected or may be affected by the task or failure, which user or users is qualified to resolve the task, a likelihood that a resolution of the task will require modifying a restricted resource, or so on). If split-entry of commands is not required (e.g., “No branch”), the task or issue may be assigned to a single user at step  915 . At step  918 , the single user may provide as input a resolution to the task or issue. 
     If, however, split-entry of the command is required, then at steps  920  and  925 , one or more computing device and/or computing platforms may determine multiple users and assign each of them the task or issue requiring resolution. Input from each assigned user may be received in steps  930  and  935 . In some aspects, steps  920 ,  925 ,  930 , and  935  may be in sequential order (e.g., a first user is assigned the task, a second user is assigned the task, the first user provides input, and then the second user provides input). In some aspects, steps  920  and  930  may be conducted synchronously (e.g., the first user and the second user are assigned the task at nearly the same time). In some aspects,  930  and  935  may be conducted asynchronously (e.g., the first user may provide input during a first time period, and the second user may provide input during a second time period, which may precede the first time period). 
     At step  940 , the computing device and/or computing platform may determine whether the one or more inputted resolutions are comparable. Once the second resolution of the task is received, a computing device and/or computing platform may compare the two received resolutions. This comparison may be a literal comparison, or may be based on one or more properties of the two resolutions (e.g., length of entered commands, variables entered, affected resources, and so on). If the two resolutions are not comparable (e.g., “No” branch), then at step  945  the result of the comparison may be presented to one or both users (or to another user of the computing environment such as a supervisor, governance user, or validation user) for correction. The correcting user or users may select one of the resolutions to use as the correct resolution. 
     If the two resolutions are comparable (e.g., “Yes” branch from  940 ), the method may proceed to step  950 . At step  950 , a computing device and/or computing platform may determine whether split-approval of the result of the comparison (e.g., a single command or sequence of commands), a corrected result of the comparison, or the result of a single user working from a task (e.g., from step  918 ) is required. If split-approval is not required (e.g., “No” branch) then the system may proceed to queue the commands from the resolution for execution at step  965 . If split approval is required (e.g., “Yes” branch from step  950 ), then the resolution may be presented to multiple reviewing users (users of the computing environment such as a supervisors, authorized users, governance users, validation users, and so on). 
     At steps  955  and  960 , key codes or other indicia may be received from a first and second reviewer. Steps  955  and  960  may occur in sequential order (e.g., a first user is assigned to review the task, a second user is assigned to review the task, the first user provides an indicia of approval of the resolution, and then the second user provides an indicia of approval of the resolution). In some aspects, steps  955  and  960  may be conducted synchronously (e.g., the first reviewer and the second reviewer are assigned to review the task at nearly the same time and provide their indicia of approval at nearly the same time). In some aspects, steps  955  and  960  may be conducted asynchronously (e.g., the first reviewer may provide indicia during a first time period, and the second user may provide indicia during a second time period, which may precede the first time period). 
     If either reviewer does not provide an indicia of approval (e.g., “No” branches from steps  955  and  960 ), then the computing device and/or computing platform may transmit a notification of the non-approval to one or more other computing devices and/or computing platforms of the computing environment for appropriate action. For example, a communication session may be instantiated between the first reviewer and the second reviewer, or between one of the reviewers and the user or users who entered the command. (The method may revert to either of step  955  or  960  so that a reviewer who did not provide indicia of approval may provide it, if for example the reviewer is now satisfied of the appropriateness of the command). If, however, both reviewers provide indicia of approval, then the command may be executed at step  965 . 
     One or more aspects of the disclosure may be embodied in computer-usable data or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices to perform the operations described herein. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types when executed by one or more processors in a computer or other data processing device. The computer-executable instructions may be stored on a computer-readable medium such as a hard disk, optical disk, removable storage media, solid-state memory, RAM, and the like. The functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects of the disclosure, and such data structures are contemplated to be within the scope of computer executable instructions and computer-usable data described herein. 
     Various aspects described herein may be embodied as a method, an apparatus, or as one or more computer-readable media storing computer-executable instructions. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment, an entirely firmware embodiment, or an embodiment combining software, hardware, and firmware aspects in any combination. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of light or electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, or wireless transmission media (e.g., air or space). In general, the one or more computer-readable media may comprise one or more non-transitory computer-readable media. 
     As described herein, the various methods and acts may be operative across one or more computing servers and one or more networks. The functionality may be distributed in any manner, or may be located in a single computing device (e.g., a server, a client computer, and the like). For example, in alternative embodiments, one or more of the computing platforms discussed above may be combined into a single computing platform, and the various functions of each computing platform may be performed by the single computing platform. In such arrangements, any and/or all of the above-discussed communications between computing platforms may correspond to data being accessed, moved, modified, updated, and/or otherwise used by the single computing platform. Additionally or alternatively, one or more of the computing platforms discussed above may be implemented in one or more virtual machines that are provided by one or more physical computing devices. In such arrangements, the various functions of each computing platform may be performed by the one or more virtual machines, and any and/or all of the above-discussed communications between computing platforms may correspond to data being accessed, moved, modified, updated, and/or otherwise used by the one or more virtual machines. 
     Aspects of the disclosure have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications, and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one or more of the steps depicted in the illustrative figures may be performed in other than the recited order, and one or more depicted steps may be optional in accordance with aspects of the disclosure.