Locations
Locations | |
---|---|
Name: | Locations |
Tech Name: | FP_Event_Locations |
Class Name: | FP_Event_Locations |
Type: | Standard |
Template: | Security_groups, Assignable, Basic |
Custom Module: | No |
Auditable: | Yes |
Importable: | No |
Reportable: | Yes |
Hide module on Main Page: | No |
Contents
Short Description
The "Locations" module offers a straightforward approach to managing organizational spaces. Users can create, edit, and store various location entries, supporting event planning. The module's entries act as references when organizing events, allowing users to quickly select appropriate venues.
Overview
The "Locations" module in MintHCM serves as a practical tool for defining various venues within an organization. It allows users to store essential details such as the location's Name, Description, Capacity, and address information. Linked with the "Events" module, it enables users to associate specific events with particular locations, facilitating straightforward event planning.
It's relationship with the "Events" module, enables seamless integration between location details and event organization. When creating an event in the "Events" module, users can select a location from the list of predefined entries in the "Locations" module. This association ensures that event records contain accurate venue information, enhancing the event management process.
Additionally, below each location record, there is an event subpanel displaying a list of all events related to that location. Users can sort these events by time, providing a clear view of upcoming events in the selected location. This feature enhances user experience, allowing for efficient event management and better organization within the system.
By maintaining this structured relationship, MintHCM users can efficiently organize events, knowing that the location details are consistent, reliable, and readily available. This integration streamlines event planning and contributes to a more organized and efficient workflow within the organization.
Fields
The Locations module comprises several standard fields, each serving a specific purpose in capturing and organizing location-related information. Here is a detailed explanation of each field:
Name | Name of the Location record. Serves as a link to the record's detailed view from anywhere in the portal, including list view. | |
Description | Allows users to provide additional context or details related to this particular location. In the "Description" field you can include any information that seem relevant to the created record. | |
Capacity | Represents the maximum number of individuals the location can accommodate. | |
Address | Captures the street address and a locale number of the location. | |
City | Records the city where the location is situated. | |
Postcode | Specifies the postal code or ZIP code of the location's area. | |
County | Indicates the county or region where the location is located. | |
Country | Specifies the country where the location is situated. |
Note: Fields marked with an asterisk on the form are required. Saving the record without providing input to them beforehand won't be possible.
FAQ
- How does the system handle instances where multiple events require the same location simultaneously?
- The system doesn't restrict the assignment of multiple events to the same location, even if their scheduled times overlap and the total attendance exceeds the venue's capacity. It allows users to assign events without checking for conflicts regarding the venue's availability or capacity.
- Can users set up recurring events tied to specific locations, and if so, how flexible are these recurrence options?
- Yes it is possible. Please refer to the Events module for further information on that issue.
- How does the system handle situations where an event needs to be moved or relocated to a different venue?
- Users can relocate events by editing event details, removing the current location, and selecting a new one from existing records. Users can also create a new location record if the location they are looking fore isn't represented by any existing record.
Custom Actions
Processes
Related Processes
Related Process Steps
Related Features
Affected by
Initiating
Related Integrations
Structure
Fields
Name | Type | Required | Validations | Visible | Editable |
---|---|---|---|---|---|
Address | varchar | Yes | Yes | Yes | |
Assigned to | relate | No | Yes | Yes | |
Capacity | varchar | No | Yes | Yes | |
City | varchar | Yes | Yes | Yes | |
Country | varchar | No | Yes | Yes | |
County | varchar | No | Yes | Yes | |
Created By | relate | No | Yes | No | |
Date Created | datetime | No | Yes | No | |
Date Modified | datetime | No | Yes | No | |
Description | text | No | Yes | Yes | |
Modified By Name | relate | No | Yes | No | |
Name | name | Yes | Yes | Yes | |
Postcode | varchar | Yes | Yes | Yes |
Relationships
Laft | Type | Right | Short Description | Relationship |
---|---|---|---|---|
Users | one-to-many | Locations | Specific Sugar user can modify many account records, but specific account record last modification was performed by specific user. | Relationship: Users - FP_Event_Locations |
Users | one-to-many | Locations | Specific Sugar user can create many account records, but specific account record can be created by only one user. | Relationship: Users - FP_Event_Locations |
Users | one-to-many | Locations | Specific Sugar user can be assigned to many account records, but specific account record can only have one user assigned. | Relationship: Users - FP_Event_Locations |