Welcome back to the third and final part of our FileMaker project management blog series. We reviewed the various types of project management solutions and established a basic set of requirements and the beginnings of an ERD for the system in part one. Then we brainstormed the workflow for our system and used a few whiteboards to make preliminary sketches of how the solution will work. Finally, we will build the application and flesh out a FileMaker project management template.
As a reminder, we're working on project tracking software that we can build using the FileMaker platform. Our FileMaker Project Management Solution blog post discussed some fundamental functionality many off-the-shelf project management applications offer and their shortcomings for users with unique workflows.
Over the years, we've worked on various project management solutions of different shapes and sizes. Yet, building a project management application seems strange, considering how many off-the-shelf project management applications are currently available – Basecamp, Jira, Trello, and monday.com, to name a few. Of course, each of these programs has its strengths, but the issue that many of our clients have is that the model those solutions address doesn't quite fit how they specifically do business.
As we discussed in our previous blog post, FileMaker has released a new feature set involving transactions. The new scripts allow us to send the changes we make to a record to the server in aggregate. So, we can batch all our changes together in one transaction and send that to the server.
If you read our blog regularly, you might remember we created a test file to demonstrate a technique on how to create multiple records at one time. We can also use the new transaction scripts to accomplish this task. For example, instead of creating 10,000 records in a loop one at a time, thereby producing 10,000 individual transactions, we should be able to submit those 10,000 new records as a single transaction.
Claris released a new version of FileMaker, and it’s pretty exciting. Of course, the usual list of bug fixes and minor enhancements to the platform accompanied the update. Nonetheless, there's at least one outstanding new feature: Transactions.
In the database world, a transaction is any operation on an entity. In FileMaker world, it represents any change made to a record. Previously, we made most of our changes to our records, one record and one field at a time. And, when we clicked out of the field in FileMaker, it committed the record, thereby completing an operation for that entity - in other words, performing a transaction. This function helps keep all our data in sync with other users who concurrently access the database. But it can impede the performance of our system, especially in a wide area network (WAN) environment with poor network speed or high latency.
In our previous blog posts, we reviewed the following:
- What a CRM is
- The requirements for a basic CRM
- How to create an entity relationship diagram (ERD) for that CRM
- How to create a CRM database in FileMaker
In this final post, we will review how to design a FileMaker CRM to finish up the system.
So, after creating the tables, fields, and relationships, the only thing left is to design the user interface (UI). Again, aiming for the most straightforward route here, our first inclination is to create a master-detail layout for each module – Contacts, Companies, and Interactions. But as we think about it, interactions are always related to a contact record; therefore, those details will live within the Contacts screen.
In our previous blog post, we reviewed what a customer relationship management (CRM) system is and put together the requirements for a basic CRM. Yet, we’re not quite ready to start writing code. Next, we need to draw up an entity relationship diagram - ERD for short. In database land, this is a map of all the buckets of information that we will track and the connected data among them. As part of this process, we will look for places to normalize the data. Normalizing means we will look for instances where we can avoid entering the same data in two different areas.
A Customer Relationship Management (CRM) tool is essential for any business. A CRM helps us communicate with clients, automates processes, and provides analytical tools to help us understand our operations and customers. That said, there are different kinds of CRMs. Some are as simple as the contacts app on our phones, while others can be full-fledged online applications like Salesforce or HubSpot.
While many off-the-shelf CRM software solutions are currently on the market, every business is unique. Therefore, invariably the need arises to customize or create a CRM system tailored to a specific workflow or value proposition.
It really is all about location, location, location. FileMaker Go makes it possible for us to collect and share longitude and latitude coordinates with the Location and Location Values functions. They’ve been around for a while but are worth a second look these days as we find more and more uses for FileMaker Go and GPS data in the workplace.
We all know FileMaker is a great platform to store, organize, and find data, be it grandma's recipes or the inventory of a multinational corporation. Most avid FileMaker users can figure out how to enter, delete, search, and even create lists of stuff with little to no help. The one thing that we often struggle with is reporting on all this data. We know that FileMaker is super powerful in this regard, having seen examples of its reporting prowess everywhere, from the Internet to personal experiences using solutions designed by others. But how to do it exactly often eludes us.
More often than not, we initially store our data in a spreadsheet. We then transfer the data from the spreadsheet to FileMaker in the hopes of expanding functionality. A spreadsheet, at its core, is a different beast. A spreadsheet is a static grid with a very intuitive but sometimes limiting method of summarizing data. For example, we can easily total the data to the left, right, top, or bottom of our “Sum” cell in a spreadsheet. This rigid grid makes it easy to count our data because of its inflexibility. This rigidity is also why most of us ultimately move most, if not all, of our data-driven workflows into FileMaker. FileMaker allows us to structure the interface and data the way we want instead of being forced to use some arbitrary grid. But, we soon find out that FileMaker's ability to organize the data the way we want comes at a price; this price is the complexity of reporting.
