Like most databases that are designed to print a large variety of reports, FF&EZ uses a system of short "IDs" to identify items in the database. This has two benefits:

1. It allows you to create a shorthand way of identifying an item that can be used on very succinct list reports, instead of needing longer descriptions that add to the length and physical manageability of a report.
2. It allows you to group and sort items in ways that make sense for your reporting needs, without necessarily relying on descriptions that might change or which don't lend themselves to the kind of sort order you want.

The IDs used in FF&EZ are meant to be alphanumeric—a combination of letters and numbers—creating a coded "shorthand" that means something to a human being. So, instead of a meaningless number, the ID gives some indication of what the "thing" is:

Here are the general rules for creating IDs (and for FF&EZ object Tags and Spec IDs):

• The ID should be constructed in "general to specific" order so that when a list is sorted by ID, all items sort into groups that are useful to you for reporting.
• The meaning of the ID code should not refer to something that could change during usage (e.g., the ID should never imply that what is now a chair is a still a rug) or which might limit how it is used (where the same chair used in one room cannot be used in another location without the ID creating confusion). This last is very common and is a holdover from the understandable needs of old, manual systems of organizing a project.
• Object Tags and Spec IDs are not permanently connected or synchronized with each other. However, it is a common practice to make make the ID of the primary specification the same as the object Tag. FF&EZ will default to this option where applicable. FF&EZ will also offer to keep these "in synch" if 1) you change the object Tag first and 2) the existing Spec ID already matches it. See the Changing Room IDs, Tags and Spec IDs topic for more information.
• If you are using unusual symbols in any ID format that might be used to create file names (such as project exports or image files), you should be aware that the following symbols are illegal in file names:
  
    \ / : * ? " < > |
  
  If your ID system has any of these characters in it and it is used as the basis for an automatic file name, FF&EZ will attempt to substitute a generic underscore character (or a "!" for the "|"). This will make it harder to locate files and folders that are created automatically, so avoid them. 

If you are planning to use the Specification screen's Auto-image utility to attach a batch of images in one operation, you should avoid using any of the above symbols in a Spec ID, since that utility depends on image names that exactly match the Spec ID. Best practice: Use the dot, dash or a space to "punctuate" your IDs, which also do not require using the [Shift] key to enter.

• When creating prefixes (as in the object tag examples above), creating too many types of prefixes may dilute the value of grouping items together. However, short two-part prefixes can work (e.g. using STGC, STGS, STGM to prefix IDs in the categories of "seating, chairs" "seating, sofas" and "seating, miscellaneous").
• The prefixes used in both Tags and Spec IDs (such as the "CHR" and "STG" examples above) can be broken out by some reports and functions to create automatic report breaks and processing groups. You can learn more about how this works and how to use them here. This is especially important if you want to use tags or IDs that start with numbers.
• For the shorter ID formats, using a very long prefix should be done carefully to avoid cramping the numeric part of an ID (if there is one). This is less crucial for short lists like project rooms but may be important in projects where there are a lot of individual art pieces or fabrics.

If you tend to create "alternate" objects or objects that use the same main product with different supporting components, a good rule of thumb is to use a "template" that reserves a spot for alphabetic suffixes: "CHR-00001A" or "CHR-00001B". This makes it easy to keep alternates in the system with meaningful tags. When a design is finalized, you can remove the suffix if desired.

• The IDs used for the lists of clients, projects and vendors are shared across the whole system, so your system for these should be well-planned and consistent. For more about Project IDs, see "Setting up Clients and Projects." You can have more than one system for these, as long as it is logical and strictly enforced.

On the other hand, the IDs used within a project (areas, rooms, objects, etc.) are completely independent of any other project. Although the meaning of any prefixes used in the ID does not nomally change, the ID itself can be changed to meet numbering requirements or to satisfy a client's own pre-established system of IDs. FF&EZ will adjust all reports and screens automatically (see "Changing Room IDs, Tags and Spec IDs" for details).

• Numbers should generally be used to simply identify different members of a large class of items. However, a short numeric prefix (1...9 or 01...99) can be used to create a specific sort order regardless of names or descriptions, especially if the numbers represent a very standardized code (such as MasterFormat or similar). However, be careful not to revert to IDs that cannot be understood by your co-workers or clients.

For more information about specific IDs, check under "Fields" on the entries for the major screens in the Design Reference.