Applications
Applications | |
---|---|
Name: | Applications |
Tech Name: | Applications |
Class Name: | Applications |
Type: | Standard |
Template: | Employee_related, Security_groups, Assignable, Basic |
Custom Module: | No |
Auditable: | Yes |
Importable: | No |
Reportable: | Yes |
Hide module on Main Page: | No |
Contents
Short Description
The Applications module within MintHCM system offers a straightforward and efficient means for employees to submit various types of applications to their superiors, people from other departments or other employees within the organization, responsible for a considered subject. This module serves as a tool for streamlining the application submission process, ensuring clarity and accountability in decision-making
Overview
Mint's Applications module serves as a tool for users to request various actions or permissions related to the categories suggested in the 'Type' field or other custom application needs. Whether an employee needs to apply for leave, request attendance at an event, seek approval for training, initiate a purchase request, explore benefits options, or submit an application of another nature, this module provides a standardized process for submission and review.
Employees can submit their applications, track their progress, and receive timely responses from designated decision makers. The status field helps both applicants and decision makers stay informed about the current status of each application, promoting transparency and accountability.
Fields
Applications module comprises several fields, each serving a specific purpose in capturing and organizing application-related information. Here is a detailed explanation of each field:
Name | Name of the application record. Serves as a link to the record's detailed view from anywhere in the portal, including list view. | |
Status | This dropdown field captures the current status of the application. It offers a selection of predefined options: "New", "In progress", "Accepted" and "Rejected". | |
Type | This dropdown field captures the type of the application. It offers a selection of predefined options: "Leave", "Event', 'Training", "Purchase", "Benefit" and "Other". | |
Decision Maker | Relation to the 'Users' module record that points out decision-making person regarding specific application. | |
Applicant | Relation to the 'Users' module record that points out the person who had submitted this application. | |
Description | Allows users to provide additional context or details related to this particular application. It should include some additional information that is necessary to process the application properly, but has no designated field. In the "Description" field you can also include any other information that seem relevant to the created record. |
Note: Fields marked with an asterisk on the form are required. Saving the record without providing input to them beforehand won't be possible.
Application Types
As mentioned before, there are several application types predetermined in Mint's Applications module. Below you'll find an explanation of each available option. Keep in mind that this available values are just suggestions on how the applications module could be utilized. MintHCM remains flexible on that issue and the following options could have a different business meaning within your organization.
- Leave: typically used when an employee wishes to request time off from work. This can include vacations, personal days, or other forms of leave. The application typically includes details about the requested dates, the reason for leave, and any relevant supporting information.
- Event: This type of application indicates that is related to some sort of an event, however it remains open to interpretation. It could be used as a request for a permission to attend some event or to gain a possibility of organizing one. Creating such record could be understood as mere suggestion that some event could be benefitial to the organization and serve as a place to share your ideas with the rest of your team.
- Training: The same way as an "Event" type, "Training" type can be tailored to meet the standards of your organization. By creating training type application record one can indicate the need of some specific training that he or his team requires, but it could also be used as a request for resources necessary for a host to facilitate a training.
- Purchase: application type utilized when an employee needs to request approval for a purchase, whether it's office supplies, equipment, or other goods and services. It should include details about the items to be purchased, their importance, and the expected cost.
- Benefit: Application type that could be used by employees to apply for some available benefits they would like to utilize.
- Other: The 'Other' application type is a versatile category for requests that don't fall into the other predefined categories. Employees can use this option to submit custom applications for various purposes, providing detailed explanations and context as needed.
Available Statuses
Status field halps maintain clarity in tracking the processing process and outomes of applications within the system. Each status serves as a clear indicator of the application's current stage in the decision-making process, ensuring effective communication and accountability. Implemented application record's statuses are pretty much self-explanatory, nevertheless you can find a brief explanation on each of them below.
- New: An application has been submitted but has not yet been reviewed or processed.
- In progress: The application is currently under review or in the process of being evaluated by the decision maker.
- Accepted: Application has been accepted by the decision maker and therefore permission has been granted to whatever applicant applied for within this specific record.
- Rejected: Application has been rejected by the decision maker and therefore permission has been danied to whatever applicant applied for within this specific record.
Typically "New" status is set right after creation of the application record and then the decision maker changes it accordingly, first to the "In progress" status and later to "Accepted" or "Rejected" depending of the application processing outcome. If applicable, some feedback from the decision maker can be provided in the "Description" field.
Custom Actions
Processes
Related Processes
Related Process Steps
Related Features
Affected by
Initiating
Related Integrations
Structure
Fields
Name | Type | Required | Validations | Visible | Editable |
---|---|---|---|---|---|
Created By | relate | No | Yes | No | |
Date Created | datetime | No | Yes | No | |
Date Modified | datetime | No | Yes | No | |
Decision Maker | relate | No | Yes | Yes | |
Description | text | No | Yes | Yes | |
Employee | relate | No | Yes | Yes | |
Employee ID | relate | No | Yes | Yes | |
Modified By Name | relate | No | Yes | No | |
Name | name | Yes | Yes | Yes | |
Status | enum | Yes | Yes | Yes | |
Type | enum | Yes | Yes | Yes |
Relationships
Laft | Type | Right | Short Description | Relationship |
---|---|---|---|---|
Employees | one-to-many | Applications | One Employees record can have many related Applications records, but a specific Applications record can be related to only one Employees record. | Relationship: Employees - Applications |
Users | one-to-many | Applications | Specific Sugar user can modify many account records, but specific account record last modification was performed by specific user. | Relationship: Users - Applications |
Users | one-to-many | Applications | Specific Sugar user can create many account records, but specific account record can be created by only one user. | Relationship: Users - Applications |
Users | one-to-many | Applications | Specific Sugar user can be assigned to many account records, but specific account record can only have one user assigned. | Relationship: Users - Applications |