This proposal is based on the development of a FileMaker solution which caters to multiple technologies. (e.g FileMaker client/server vs. web vs. mobile)

Distinct files for each technology

Essentially, the best practice is to use a separation model with the following files. Important Note: the names of the files are not explicit. They are simply representative of what technology each file would interoperate with. Additionally, there is no limitation to the number of any given type of file. For example, your solution may use one (1) data file, three (3) different FileMaker interface files, based on departments or some other classification, and one (1) FileMaker mobile file.

DataFile{n}.fp7
FileMakerInterfaceFile{n}.fp7
FileMakerIWPFile{n}.fp7
FileMakerCustomWebFile{n}.fp7
FileMakerMobile{n}.fp7

Note: the {n} above implies that multiple files may be used in your solution.

Beyond the number and interconnections between Data files used to store centalized solution data, one (or more) files can be used for each distinct technology.

The primary reasoning behind this convention is to separate application logic layers into distinct files. This not only compartmentalizes them, but facilitates more coherent and simplified organization.

Using external data references, any one file can certainly call any other file to access common or shared functionality (dry practices).

Shortcomings

The above development model does have a few shortcomings. One of them is the required duplication of Security settings when any one given setting may work for all files. It would also be easier to manage account authentication via FileMaker's support for external authentication.