This page is for the add/edit custom fields for the flex grid. The page has one form at the top that will be used for both adds and edits. There is a max of 30 custom fields per main application type. Check the main submit button to see what mode the page is in.

Small note about the settings on this page: When setting up a custom field names, there will be a field called the "interaction type". This is where you choose what you want your users to see when they use these fields. The default is an open entry field which means that the user will be able to type the values in to the field. There are also options for creating your own dynamic drop-down lists of values. If you choose one of those options (dynamic lists), you will need to build your own list of options by clicking the [add sub] link that is shown by the custom field name. The dynamic lists help you to standardize or speed up data entry. It is ok to mix and match interaction types as needed.

The flex grid tie-in application is a standalone mini application that rides on top of the entire main Adilas.biz platform. Think of a virtual "buddy system" of sorts. Another good way to think of it is a "custom database" that is specific to your needs. The flex grid is used for connecting things together, creating special relationships, recording additional information, and assigning dynamic tie-ins. You may also use it to tell a story, recording extra details that are not included in the normal application flow, log activity, provide support, etc. It is very flexible and may be configured to meet your needs. If you like football, the flex grid is kinda like having an awesome "all-around rover" on the bench, he only plays when needed, but does an awesome job. He loves to hear the words "you are in - go play".

If you are looking for more basic flex grid information, please see the help file for the main flex grid homepage.

Technical Information About The Custom Field Names:
In a nutshell, you get 30 custom fields per main application type. If you do the math, that is a total of 360 different fields (12x30=360) that are possible. They are not required but they are there if needed. Have fun and be creative. This is how you customize your stuff.

On a more in-depth note, the flex grid is a way to tie things together or make assignments between main application types (existing system players). As part of those assignments, we allow a number of special fields to be recorded with each assignment. Each assignment is specific or tied to just one main application type. This means that each piece of flex grid gets flagged and assigned to only one of the 12 main application types or players per piece of flex grid. This may feel a little bit technical, but hopefully it will help explain what is going on.

Each piece of flex grid has four main sections or parts. This is way down at the database and storage level. They are:

1. What is the main tie-in?
2. Are there any subs or sub tie-ins?
3. What are the custom fields?
4. What are the general fields like notes, dates, and amounts?

If you understand that each piece of flex grid has these four parts (see list above) it will really help you understand what is going on.

Let's start with the first section - What is the main tie-in? Each piece of flex grid may only be tied to one main player at a time. For example, say I have a customer and I want to add a piece of flex grid to that customer record. When I do that, the new piece of flex grid is only tied to that customer as the main tie-in. This main tie-in tells the computer where to make the record show-up and who its main buddy is. This is like setting a master or a host status to the main player involved.

The second section - Are there any subs or sub tie-ins? This section allows for buddies and special handholding. In plain English, it is like saying: I want you (main player) to always be connected with you (talking to the sub player). Once you set this up, a relationship exists between the two parties. Wherever you start, that is the main. Who ever gets added to that assignment is the sub. If you wanted to get fancy, the system will allow multiple assignments as well. In English once again, this would be like saying: I want you (main player) to hold hands with you, you, you, and you (assuming that as you said "you" it meant a different sub player). In a way, this is how you set the "virtual buddy system". This entire second section (are there any subs?) is completely optional and is not required.

The third section - What are the custom fields? This gets into the custom fields that we allow per main application type. These special fields allow you, as a user and/or as a company, to store special data that is not already included inside the main Adilas.biz application (extra or special fields). We will explain this deeper later on, but for now, just assume that you get 30 custom fields per main application type. Similar to section two, these fields are not required.

The fourth section - What are the general fields like notes, dates, and amounts? These fields help the system hold and track general things like: What is the relationship type? Is there a location involved? What is the date that this happened? Should I hold a specific amount? Should I show this to everyone or keep it only for admin users? And are there any general notes that should be kept with this piece of flex grid?

Once you understand that each piece of flex has these four parts (see above), it will help you know what we record per piece of flex grid or per assignment.

If you are still with us, let's keep going deeper... Think of each piece of flex grid as an assignment that gets made in the virtual buddy system. Each time a new piece of flex grid is added to the database, the database records 55+ fields of data per record. That may sound like a lot, but it really isn't. Of these data fields, 30 are generic fields that can hold additional data. Behind the scenes the generic fields are called "other 1", "other 2", "other 3", ... until you get to 30 or field "other 30". These generic fields are where the actual custom or special data is stored. Because most people don't want to call their custom fields other 1, other 2, etc., we allow you to create a name or dynamic title for the fields. This becomes somewhat of an alias of what to call your custom fields. These names may be specified for each of the main 12 application types (system players).

Each underlying generic field (other 1, 2, 3, etc.) can have up to 12 different aliases for the same underlying field (where the data is stored). The reason each main application type doesn't have its own fields is that would be 360 special fields (12x30). Instead of having all 360 fields, we just use the same 30 generic fields and use them over and over again. Once again, each piece of flex grid can only be tied to one main player at a time. We simply flag each record and say something like: Pretend that you are in the vendor/payee mode. Or pretend that you are in the invoice mode. Each record is only able to hold one main tie-in.

Here is an example of how we use the same underlying field (other 1, other 2, etc.) over and over again. This is done to help with database storage requirements per record: Say you wanted to call your first custom field something like "Income Level". This would be done for the main customer application type. Say you also wanted to call your first PO field "Product Serial #". Either way, the underlying data is recorded in the generic field "other 1" but it is called different things depending on if you were dealing with customers or PO numbers (aliases per application types or per main player types). The reason this works, to have just 30 generic fields, is that each piece of flex grid is only assigned to one main player at a time. This allows us to reuse the generic fields over and over again based on what the main tie-in value is. For example: Am I tied to an expense/receipt? An employee? An Invoice? A Customer? A part number? What?

The cool thing about the aliases or dynamic field names is that they will follow you around depending on what you are dealing with or what you are searching for. In the example above, If I wanted to add a new flex grid tie-in for a customer, the other 1 field will always be called "Income Level". The data that I enter will be recorded in the generic field "other 1" but as far as I'm concerned, it was recorded in the "Income Level" field (kinda like smoke and mirrors). When I go to search the flex grid tie-ins for customers, you guessed it, I would see all of the data that was entered under the "Income Level" field. In real life (speaking technically), the generic "other 1" field holds the actual data but I get a good feeling because I see the alias "Income Level" (custom field name according to the application type). The field titles and/or field names you set on this page become the custom field names (alias names) for the extra fields.

Additional Information - If you want to keep going a little deeper:
Sometimes people get confused because the flex grid tie-in application uses the numbers 12 and 30 over and over again. Remember, the whole flex grid application is a virtual buddy system of sorts. Without getting too technical, here is why we use the numbers 12 and 30. We have determined 12 main tie-ins (system players), 12 sub tie-ins (buddies to the main players), and each record has up to 30 custom or generic fields that may be used. This creates a possible 12x12x30 matrix and thus the name flex grid or flex grid tie-in. In short, think buddies and assignments between buddies.

The 12 main application types (system players) are: deposits, invoices, PO's, expense/receipts, user-maintained balance sheet items, stock/units, customers, vendors, employees, part numbers, elements of time, and quotes. We call them the main application types (players) because this is were the tie-in originally comes from. This is the first set of 12.

The 12 sub application types are a way of telling the system "who is my buddy?". They, the sub 12 players are the same as the main application types or players but are considered subservient to the main. For example: Say you wanted to create a relationship between Tom and Sally (two customers from the same family). If I started on Tom's record, he would be the main player. Sally would then be the sub player. Even though both Tom and Sally are physical players in the system, the value of main or sub just depends on where I start from. If you wanted Sally to be the main player, you would start and create the relationship beginning with her first. At that point, she would become the main and Tom would be the sub. As a note, these sub tie-ins are available but are not required.

Having this main id to sub id relationship allows us to connect, different players together in any way we need or want. For this example, don't worry about the actual numbers being used, think more of the concept behind it. For example: Say we had main invoice #12 and tied it to sub expense/receipt #332 to show a commission that was paid on invoice #12. If you land on invoice #12, it will point to expense/receipt #332. If you land on expense/receipt #332, it will point you to invoice #12. If everything is done correctly, you just created a full circle of who the players are (hence the buddy system analogy). This same main to sub relationship opens up the potential for the system to connect invoice to invoice, customer to customer, a single PO to multiple invoices (items coming in and items going out at different times), or any possible combinations of parent/child, brother/sister, or master/detail relationships. This is the second set of 12 or who are the sub players? As a note, this sub tie-in section is set to 0 by default. This means that it is not required but exists as an option if needed.

The third number set jumps from the number 12 to the number 30 and is for the custom or special fields. These are extra or custom fields to help hold and organize your data. Most times, these fields will hold data that is not recorded anywhere else inside of the main Adilas.biz application. If you want to take it one step further, each of these 30 generic fields may contain up to 12 custom dynamic field names or aliases. The 12 aliases don't hurt the underlying data at all, they just allow for the 30 generic fields to be called whatever they need to be called for each of the main 12 application types (main system players).

Now you can see why the flex grid tie-in application is its own little application built on top of the main business platform. The whole thing deals with a term we call "roll call". What is the story? Who are the players? How are they connected? When did this happen? Etc., etc. Ideally you do an action, tell the story, tie everything together, start anywhere, go full circle, and come back around. Pretty cool! :)

If you want more info, see the help file for the flex grid tie-in homepage. There is also a graphic there that shows the relation between the main and sub application types.

« Back . [contact Adilas support - email form]