There is no need for a separate file or even a separate table. There are a number of different ways to design the interface and use FileMaker's built in security to limit a user's access to only "their" data.
On option is to use a set of fields with global storage specified to collect the user's input. If they click a button or check box to indicate that they are a returning customer, your system can pop up a search tool which, if it finds their record, copies their contact data over to the global fields so that they can review and edit it. When the user submits the data, this contact data is copied back into the contacts table--either into a newly created record for new customers or to the existing record found in the search for returning customers. Any data that is not part of that contact record--such as a request for service, can be put in a new record in a related table linked to the person's contact record for review. A status field in that record can record what has been done with that request.
Hi Phil thanks again,
I like your global field concept.
However, some stakeholders with veto privileges on this project are exquisitely concerned with privacy and may be concerned that users could access contact details either deliberately (by entering in a name that is not their own) or accidentally if they have sufficient similarity in match criteria.
Perhaps I need to learn more about FM13 security and get better at communicating about it.
I had also considered generating user accounts with email address as the account name and get (UUID) as a calculation for generating passwords - this would be emailed to the client (from the server?) for access to the form to ensure the request is actually coming from the email account holder.
I found the following recent post on email addresses as account names
And this one on restricting access to records
The following is a bit of a rant on effective consultation in development and could be ignored by busy forum readers.
My separate file concept is no doubt redundant but was conceptualized as a very obvious and visually demonstrable way of mollifying concerns about ‘backdoor access to data via the web’. This phrase gets bandied about a fair bit around here (my workplace) and was instrumental in terminating a very expensive, ill conceived and poorly researched/managed attempt to resolve many of our booking/client interaction problems. Unfortunately, throughout this process our institution (the primary users but non budget holders) were poorly consulted and multiple significant concerns remained unaddressed. When the project (a slow train wreck from our dismayed perspective at the time) unraveled we were left with our original systemic problems PLUS a managerial / institutional ‘bitter taste’ as regards attempts to address it and a somewhat exuberant institutional aversion to web based solution elements.
I personally had a very instructive observation/lesson in development planning consultation deficiency from the perspective of the primary user of the solution.
FileMaker certainly can function with multiple files--it was originally designed to function with only one table to a file and this multi-file capability has always been supported. I was just pointing out that it was unnecessary and that it doesn't really add much true security to the design since the data in this other file still has to be accessible to the first. One of the complications that arise from multiple files is that each file maintains its own accounts and passwords so setting up a new account requires creating an account with identical name and password in both files.
It is possible to use a script--typically set to run with full access privileges that creates new accounts with an assigned password and specified privilege set. Such could be run from an EmailAddress entered into a text field and Get ( UUID ) can specify either their permanent or temporary password. And such a script can ensure that accounts with identical credentials are created in each file of a multi-file system.
Only problem there is that the text of the UUID is very long for a password. But passwords need not be unique, only account names and you can assign an initial default password and require them to change the password the first time that they log in.