FileMaker Portals Swapping Data With Each Other

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

There are times that you may want to copy data from one child table to another ... or ... move data from one file to the next. It is not that uncommon that a database is used by multiple users to track business events. Think about a database that is used in an approval process, such as a returns. I speak from experience on this one because one of my first really complicated databases involved a nationwide returns operation for a temporary rash of faulty equipment.

In this process, a staff of general data entry individuals would enter in the particulars about a customer request for return of a product. These records would be entered in with a status level of Pending.

Then a staff of managers would log into the database. The first thing they we see is a list of "pending" returns from their employees in a portal. They would have the option of clicking Approved ( which would move the return up the status ) or Denied ( which would refuse the return and move it back down the process).

The denied claims would then appear back in a portal for the person who entered the original request. They would need to contact the customer and discuss it with them. The approved claims then would appear in another layout used by administration.

They would fax or mail the customer the returns agreement. When the customer returned the signed paperwork, then the admin person would mark the record in the portal " Awaiting Return."

These next step was to wait for the product to be returned. When it was returned, the staff in the shipping department would log into the database and enter in products that were received. That would clear the record for replacement units to be shipped or credit given to the customers account.

Next the shipping department would send the replacement product or the accounting department would issue a check. The database was again modified by these users so the records would then hit the final level of closed.

All these levels had separate screens in the database with portals that showed records in a particular status marker. This way the return could be tracked at any time and you could see who touched the return and when.

You might be thinking " the data isn't moving from one file to the next, it's just changing data in the status field" and the portal is reflecting those changes. Well, sometime the real world steps in. In this case, some of the databases already existed that did these processes and the managers did not want to give them up. So literally one departments database needed to move data to another departments database and so on. After 6 months though, a more and more of the databases started to integrate into one big FileMaker solution.

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.