When bulk importing data into your FMX site, there are a few different templates from which you can choose:
- Maintenance Request
- Planned Maintenance
- Schedule Request
Choosing the correct template depends on the type of data you are importing.
Within these templates you will see several different columns, some with asterisks (*), and some without.
*Note: Any column with a * MUST be completed (no blank cells), or else your data will not import!
Let’s break down the different import templates so that you can better understand what each column means, as well as any common issues that we tend to run into on a frequent basis when bulk importing data.
Most often, template columns will vary between different customers, as each are specific to every individual FMX customer’s site.
**Important note: When it comes to required fields (*) on ALL templates, make sure that each cell is spelled/typed EXACTLY as it appears on the customer’s FMX site, or else it will not be recognized during import. You will most likely need to make some necessary edits to their data, or on their site.
Buildings are one of two REQUIRED pieces of information to begin using FMX. These are simply just the buildings that can be found on and around a customer’s property (i.e. The schools that make up a district, or the residential and recreational buildings that make up an apartment complex, etc.)
Name: To begin, make sure to NAME your building (see the * ?) This is the ONLY part of this import that is REQUIRED.
This name could be anything from, “Indian Springs ES” for a school district, to “Leasing Office” for a property management company. Buildings can ALWAYS be added to your list at a later date, and they can even be deleted, but be careful! Deleting a building will ALSO delete everything and anything associated with that building.
Address, Phone, Entrances, Additional comments, Area (sq ft), Emergency info, and Year Built: These are all areas where you can insert details about each building; however, they are not a requirement when creating a building.
And lastly, when it comes to Custom field, this is where a customer can add any additional information regarding their buildings if they should need/want to.
Resources and Locations are areas within or outside a building. Resources are schedulable rooms or items (i.e. Gymnasium at a school; laptop carts). Each resource/location must be assigned to a Building.
Name*: This is where you name the resource or location. Make sure this name is unique and recognizable:
Name: Auxiliary Gym
Building*: This is where your resource can be found.
Name: Auxiliary Gym
Building: Dublin Scioto HS
Address: This is not required, but can be included if the customer wants.
Location: This is where you would type ‘yes’ or leave blank. If a resource is also considered a location, then you can attach several different resources to it.
Building: Dublin Scioto HS
Location: Auxiliary Gym
Location 2: Weight Room
If a location is SCHEDULABLE, then it is something that users (depending on their schedule
request access) can schedule to use/rent, depending on the customer.
This is why the Resource Import template also contains the Schedule Request Settings section:
This is where you will fill in the details regarding the location’s schedulable settings:
Requires approval: This is a “yes” (or leave blank if no) response. Does scheduling the weight room in the Auxiliary Gym at Dublin Scioto HS require someone’s approval before a guest can use it?
Requires estimating: This is a “yes” (or leave blank if no) response. If scheduling the weight room in the Auxiliary Gym at Dublin Scioto HS costs money, then there needs to be an estimate sent to the requester that tells them how much this will cost.
Requires invoicing: This is a “yes” (or leave blank if no) response. If a cost estimate is created and sent to the requester, then an invoice will be created where they will then pay the owed amount for this request.
Quantity: This is a “yes” (or leave blank if no) response, followed by a ‘ALT+Enter’ Excel shortcut that adds another line to the cell containing the quantity amount (this only applies if the answer is ‘yes’).
Disable conflicts: This is a “yes” (or leave blank if no) response. Does someone (a specific User Type) have access to go into this request and disable any scheduling conflicts that might have arisen?
Permitted user types: This is where the customer would use ‘ALT+Enter’ again to create separate lines within the cell. Which User Types will have access to specific schedulable resources/locations? This will vary based on each resource/location.
Approval Order: This is where the customer would enter the approval order based on User Types (using ‘ALT+Enter’), and/or which users can access these schedule requests after business hours.
When creating an FMX site for a company, customers will need to import all the people, or as we call them, Users, associated with their company into their site. These Users will be assigned User Types (Admins, Maintenance techs, Staff, Community Member, etc.) These different User Types will allow different Users to have different levels of access within the company’s FMX site. Users can always be added or deleted at any time.
Name*: This is the person’s name. Make sure it is easily distinguishable from other Users (First and Last name typically takes care of this).
Email*: This is required unless the user is just being stored as a contact. Make sure the email is a verifiable address that the User can confirm in order to activate their FMX account. (Duplicates are not an option here).
User type*: This refers to how much access this user will be permitted within the site. If a User’s User Type is Community member, then they will not have much access to the site other than scheduling requests. If a User’s User Type is Building Administration, then they are going to have most, if not full access to the site. These allowances can be modified for each User Type, but only by other User Types that have the permission to Administer (make changes) within the site.
Time zone: This is used then a customer has users who are located in different areas across the country/world.
Password: This can be auto-generated by an FMX Admin, but typically the User is sent a link where they can create their own password.
Require password change: This is a “yes” (or leave blank if no) response. This is used if you assign each User a generic p/w such as “welcome”, then they will be required to change it once they verify their account.
Building access: Using‘ALT+Enter’, you will enter in all of the buildings to which each user has access.
Phone: Provide a number in which each User can be reached.
Labor rate: If applicable, what is the User’s hourly rate? (This is kept private from other Users, of course).
Can be a driver: This is a “yes” (or leave blank if no) response. The only way a User can be assigned in a transportation request to drive a vehicle is if they are marked as a driver.
Liability insurance expiration date: This only applies to Users who are required to have liability insurance.
Is contact: This is a “yes” (or leave blank if no) response. A customer might just want to add people in as contacts rather than Users, giving them easy access to their contact information. If a person is just a contact, then they will have no access to the customer’s FMX site.
Is supplier: This is a “yes” (or leave blank if no) response. A customer might have suppliers whom they want to store in their site. These suppliers can be people or companies in which the customer outsources for certain tasks/resources. This gives customers easy access to their supplier’s information, while also giving the supplier no access to the customer’s FMX site.
Custom Field: Again, this is always an option if a customer needs to add any other required/non-required details to their equipment items.
Equipment items are fixed assets in which a customer will want to track a maintenance history. This can be anything from a vehicle, washer/dryer, fork lifts, lawn mowers, etc. Equipment can often be mistaken with inventory; however, inventory is not considered an asset, but rather a disposable resource.
Similar to the Building Import template, this template also has required fields, as well as fields that are not essential to the import.
Tag*: This is referring to the NAME of the piece of Equipment (e.g. Walk in freezer, Lawn
Type*: This is referring to what equipment type each specific piece of equipment should be assigned to.
Tag*: Oven A
**Equipment Types must be created PRIOR to importing this data
Building*: This is referring to WHERE this piece of equipment should belong.
Tag*: Oven A
*Note: Equipment cannot be properly imported unless you have created the accurate TYPES as well as imported the accurate BUILDINGS prior to importing
Location: This is not a required field in this template; however, it does not hurt to include locations if there is quite a bit of equipment to enter. Locations are created prior to importing most data, because some templates have Locations as a required field.
Tag*: Oven A
Inventory items, Manufacturer, Installed date, Website, Comments: These are not required fields; however, depending on the customer, some of this information may be necessary for them to record for each of their equipment items.
Custom Fields: Again, this is always an option if a customer needs to add any other required/non-required details to their equipment items.
Inventory items are used to track consumable items or spare parts such as light bulbs, spare parts, air filters, etc.
Name*: Here customers will name their individual pieces of inventory. Just like equipment, make sure that this name is recognizable, or somewhat unique.
For example, instead of using “Pipe - 6 in.” you might use “Cast Iron Pipe - 6 in.” If the data the customer has sent you does not contain unique names like this, then you may have to get creative with your Excel skills in order to make sure each item is distinguishable from the next.
Type*: This is where each piece of inventory is assigned to a previously created Inventory Type, such as “Maintenance” or “Housekeeping”. Some customers can get very specific with their types (Pool Maintenance Parts), while others are more general. *Always double check to make sure these types have been created on your customer’s FMX site prior to importing. If they haven’t, then you can create new ones for them to match their data (or you can modify their types on their data to match what they already have on their site).
Building*: Again, just like equipment, each piece of inventory needs to “belong” somewhere.
For example, maintenance parts will most likely be stored in the “Maintenance Storage” building. Just make sure these buildings exist on the customer’s site prior to importing.
Location*: This is a required field. Locations are places in or around a building that helps a customer narrow down exactly where something can be found.
For example, within the “Maintenance Storage” building, there might be the “Spare Parts Room” where your 6 in. pipes can be located, and even more specifically, the spare parts room can be a“Parent Location” for Cabinet A > 2nd shelf.
So, as you can see, locations do not have to be just specific rooms; they can also be shelves within a room, or cabinets within a kitchen. The options are limitless!
Current Quantity*: This is crucial for customers to record since they need to keep track of how much inventory they have left and how often they use specific pieces of inventory. This helps customers when they are making their routine purchase orders.
Minimum quantity: This is not required, but some customers like to use this feature, as it notifies them when they are running low on resources.
Unit Price: This is not required, but can help give a customer a better estimate of how much money their inventory costs them, possibly helping them to cut down in certain areas if need be.
Assigned users:This is not required, and is used if only specific users are assigned to certain pieces of inventory.
i.e. “John Snow”, the Electrician,is assigned to all electrical parts.
Suppliers: This is not a required field. Suppliers are created when a customer creates their users/contacts (or they can be added anytime). A supplier can be listed on a customer’s site, but not be considered a user, giving them no access to the site.
i.e. “Sherwin Williams” is a supplier for all of the paint at an apartment community.
As for Custom fields, you might see “Model number” or “Serial number”; it just all depends on the customer’s needs and preferences.
Maintenance Request Import
This import is typically used when a customer has maintenance requests that have previously been placed and executed while they were using a program or software before transitioning to FMX. With this bulk import option, customers have the ability to keep a record of their previously executed tasks to look back on when necessary.
**This template is also the same as the Technology Request Import Template
Requests Sheet - This sheet will contain the specific details regarding the maintenance, technology, and custom work requests which will be referenced on the subsequent sheets.
Name*, Building*, Request type*: This information is the same as what you will find on the other templates. They are all required fields, and they must reflect what is already in place on the customer’s FMX site. These can always be added to their site if need be.
On behalf of: This would be filled out if the request was made on the behalf of someone else.
For example, The Building Admin made a maintenance request on behalf of the Maintenance Director because the Maintenance Director was unable to do it at the time/etc.
Location, Equipment items: This information is the same as what you will find on the other templates. Where specifically does the work request need to be executed? Were any Equipment items necessary in order to execute the task? These are not required on this import.
Due date*: This required field is asking when the work request’s due date was.
Description: This is not a required field, but it can come in handy when customers are trying to be specific when scheduling work requests.
Created Date* and Time*: These required fields are asking for the time and date in which each work request was created.
User*: This required field states which user created each work request.
Followers: Users can tag Followers on each work request they create so that others can see the details of the request.
Assigned Date and Time: When and at what time was each request assigned? (date: MM/DD/YY).
Assigned users: If a task was assigned to a particular User, to which User was it assigned?
Outsourced: If this request was outsourced, to whom was it outsourced? This can include more than one supplier if need be.
Custom Fields: Again, this is always an option if a customer needs to add any other required/non-required details to their work requests.
Response Sheet - This is where the supervisory responses to the maintenance, technology, or custom work requests are stored. Information is typically entered here when transferring historical data into a customer's FMX site.
Request*- Reference the name of the request as recorded in the Requests Sheet Name column.
Date* - The date of the response to the maintenance,technology, or custom work request.
Time* - The time of the response to the maintenance, technology, or custom work request.
User* - Record the name of the user responding to the request. User names must match what already exists on a customer's FMX site.
Response* - The response provided to the user regarding the request.
Resolution Sheet - When a resolution is reached, this is where the customer inputs the details of the resolution. Information is typically entered here when transferring historical data into a customer's FMX site.
Request* - Reference the name of the request as recorded in the Requests Sheet Name column.
Date* - Enter the date of the resolution.
Time* - Enter the time of the resolution.
User* - Provide the names of the users providing notification of the resolution. User names must match what already exists on the customer's FMX site.
Cost - Record the overall cost of the resolution.
Hours - The number of hours worked toward the resolution.
Resolution* - A description of the resolution and the work performed.
Reopening - In the event of a reoccurring problem on a previously resolved maintenance, technology, or custom work request, provide details regarding ticket reopening on this sheet. Information is typically entered here when transferring historical data into a customer's FMX site.
Request* -Reference the name of the request as recorded in the Requests Sheet Name column.
Date* - The date the maintenance, technology, or custom work request is reopened.
Time* - The time the maintenance,technology, or custom work request is reopened.
User* - Provide the name of the user reopening the ticket. User names must match what already exists on your FMX site.
Reason* - Describe the reason for reopening the ticket.
Planned Maintenance Request Import
The Planned Maintenance Import Template can be used to mass import planned maintenance tasks and instruction sets into your FMX site.
Instruction Sets Sheet (this sheet is optional): Instruction sets are detailed step-by-step checklists that you can associate with planned maintenance tasks. Follow the steps below to create an instruction set
Name*: This will be the name for the step-by-step checklist (e.g., HVAC Monthly PM, Check Belt Tension).
Description (optional): This is where customers can describe what the instruction set will be used for.
Steps*: This is where customers list all of the steps in the checklist. Type one step then press Atl+ Enter to enter the next step. Numbering is not required.
Tasks Sheet: Tasks are recurring planned maintenance events in FMX
Instruction Set (optional): This name must match what is entered in the "Instruction Sets" sheet or what already exists on the customer’s FMX site. If no instruction set is required for the task then leave this cell blank.
Name*: This will be the name of the task (e.g., AHU #1 Quarterly PM, Check Belt Tension – Monthly).
Building*: This is the building where the task will take place. Building names must match what already exists on the customer’s FMX site.
Equipment (optional): This will be left blank if the task is not associated with equipment. If customers want to associate the task with equipment, this is where they would add the Equipment Tag (e.g., AHU # 1, Exhaust Fan 12, Fire Extinguisher). Equipment names must match what already exists on the customer’s FMX site.
Due Date*: This is the first time the task will occur (format should be mm/dd/yy).
Repeat*: This is the frequency of the task occurrence (Daily, Weekly, Monthly, Yearly).
If Daily, then they will have stated Every X days (e.g., enter a 1 for every day, enter a 5 for every 5 days).
If Weekly, Sun-Sat – then they would have entered a 1 in all days that it should occur. Every X weeks, they would have entered how many weeks they want this to occur (e.g., put a 1 for every week, put a 4 for one week out of the month).
If Monthly, they would have selected a mode:
Day of the month: The task will repeat on the same date (e.g., the 20th of every month).
Day of the week: The task will repeat on the same day of the week (e.g., the first Monday of every month).
Weekday of the Month: The task will repeat on the same date unless it falls on a weekend in which case it is rescheduled to the nearest weekday.
Weekend Day of the Month: The task will repeat on the same date unless it falls on a weekday in which case it is rescheduled to the nearest weekend day.
Every X months - how many months they want this task to occur (e.g., put a 1 for every month, put a 3 for every 3 months)
If Yearly, they would have entered Every X years: how often they would like it to occur (e.g., 1 for every year, 4 for every 4 years).
Assigned users (optional): This is where the customer would enter the email address of the person they wish to assign to this task. If they would like to assign multiple users then press Ctrl + Enter to move to the next line. User names must match what already exists on the customer's FMX site.
Outsourced: This is where they would have entered a 1 if the task is outsourced and enter a 0 if the task is internal.
Schedule Request Import
The Schedule Request Import Template can be used to mass import customers’ schedule requests from their current scheduling system (Google, Outlook, etc).
Name*:This is where the customer would have entered the name of each scheduled event (e.g. Weekly Meeting).
Request Type*: This is the category of each request (e.g. Community, General, etc.) These must match what already exists on the customer’s FMX site.
Building*: This is where the customer would have entered the building where the event will take place. These must match what already exists on the customer’s FMX site.
Resources*: This is the location of the event. If the event will have multiple resources or locations, the customer will enter the first one and then hit Alt+Enter to go to the next line to enter more locations (e.g. Room 201). These must match what already exists on the customer’s FMX site.
Created Date*: What day was each event created? Must be enter as MM/DD/YY.
Created Time*: What time was each event created?
User*: This will include the name or email addressof the person making the request. Make sure this user is a user on the customer’s FMX site. Note if this user requires approval, all requests will have to be approved.
Date*: What day will the event be held? Must be entered as MM/DD/YY.
Start Time: This is the time that the event will start. Note: This will not be included when entering an "All Day" event.
End Time: This is the time that the event will end. Note: This will not be included when entering an "All Day" event.
Setup Duration (minutes): This is how many minutes are needed for setup.
Tear down Duration (minutes): This is how many minutes are needed for tear down.
Repeat*: This is how often they want this event to occur (e.g. Never, Weekly, Monthly, Yearly). The next columns will be filled out accordingly based on how often the events occur.
On behalf of: This would be filled out if the request was made on the behalf of someone else.
Technology Request Import
**See Maintenance Request Import
Transportation Request Import
The Transportation Request template allows for customers to import upcoming or previously executed transportation requests, such as field trips at schools, sporting events, etc. With this template comes many different custom fields, all depending on the type of industry the customer belongs. Most often we see schools use this module more so than other industries.
Name*: Make sure the name of each request has a uniquely identifiable name
Request Type*: Most often this request type is set to "General", but it can be modified to be more specific.
Building*: At what building is this request being made?
Pickup location*: This needs to be a previously created location that is located at the building in which the request is being made. (e.g. Main lobby, SE Entrance, Red Lot).
On behalf of: This would be filled out if the request is being made by someone for someone else. Not ever user has this access.
Destination*: Where is this trip going? Another school? A museum? This is a required field, so make sure it is completed!
Departure Date and Time*: This is a required field. What day and time will each trip be leaving the location assigned?
Return Date and Time*: This is a required field. What day and time will each trip be returning to the location assigned?
Created Date and Time*: When and at what time was each request created? This is a required field.
User*: Who created each request? This is a required field.
Assignment: Have specific drivers (these are Users in the customer's site who have been specifically marked as being a driver) been assigned to each request? Specific vehicles?
Common Custom Fields in a Transportation Request Template:
Handicap bus required (yes or blank if no)
Number of passengers
Number of vehicles
Staff member in charge
Purpose of trip
Overnight trip (yes or blank if no)
Will stop for meals (yes or blank if no)
For more on Bulk Import Templates, click the links below!