I am finally getting around to playing with Claris Connect and, to borrow the tagline from McDonalds, I’m lovin’ it!

I am finding that I have to think a little bit differently to get my workflows to do what I want. My default logic is to step through the flow like I would in a FileMaker script and while that works for some things, it doesn’t work for all things. For instance, I have a result from one step giving a timestamp result that looks like this: “2023-08-28T17:00:00.000000Z”. I need the date and time separated and need it translated into the central time zone. I know exactly how to do that in FileMaker scripting and could do it in 2 steps – one step to grab my date and change it into the format I want and one step to grab my time and change it to the time zone I want. However, in Claris Connect, I have only the Dates Utility to work with and have to do some manipulation to get what I need. In my case, the workflow is triggered by the creation of an event. Before I can translate the date format into the date/time I need, first I have to request the event details from the app, then I can complete the two steps to grab my date and time.1 It took me a number of trials and errors to get what I wanted and it still takes more steps then it would have in FileMaker.

Nonetheless, the more I use Claris Connect the more I like it!

The first “cool new thing” that I created with Claris Connect is a support request workflow. It’s working beautifully and is a fabulous way to reduce phone calls, text message, and/or emails sent to (potentially) the wrong person or sent to the right person, but at the wrong time (ie sending me emails while I’m on vacation isn’t going to get you a very fast response time!).

In each client’s file I created a card window with 6 global fields: User Name and contact info (2 phone #s and an email), Priority, and a Description2. When they hit “Submit,” the script triggers a flow in Claris Connect (keep in mind, this is a new script step that’s only available with FileMaker Pro 2023) to send their request to our Slack workspace. Here, we post the requests to channels that are monitored by multiple people. We are using 4 priority levels: 911, High, Medium, and Low. If the user selects 911, we are pushing their request to our 911 channel that the entire staff has access to and for which we have round-the-clock coverage. Otherwise, the request is posted to the client’s channel for which the staff that work on that client’s project have access.

Yes, I have accounted for users who haven’t upgraded to FileMaker to 20 yet, and I have it set to send an email to the core team instead. While that response time will be a little slower than the Slack post, it’s still faster than a client sending the request to someone who is on vacation or to the wrong person entirely.

This was just my first flow! I’ve created several more in the last couple of weeks and have nearly another dozen ideas for the weeks to come….

I’ve included two short videos showing the user creating the request and what our post looks like coming in….then a quick peek at the flow in Claris Connect. Check out the videos, as well as the extension ideas below, and create your own variation!3 When you are done, post a reply with details about your variation…let’s keep the ideas flowing!

Support Ticket & Slack Post

Claris Connect Workflow

Extension ideas:

You could create a “utility” script in FileMaker just for this purpose. You could send that step result over to FileMaker to run the two steps and send the results back.

Two possible extensions here

Since I’m using global fields, my solution doesn’t store support requests/data, however, this could easily be modified to store those requests in the client file and/or in a separate file. Then, if you had a paid Slack account, you would be able to use their webhooks to post the resolution data back in the client file.

I have only the 1 field for the user to write out their concern/issue (as well as my script captures what layout they are on when they submit the request). I’ve considered adding a container so that the user could upload a screenshot of their issue. Additionally, I’ve considered adding a json field to each table that would capture some basic details about the record. Both of which could be posted into Slack in that post, which would give the developer a LOT more information about the user’s issue.

I chose to use a single workflow to manage all of our client support requests, as it’s easy to duplicate the 3 steps (if, post, stop flow). However, you can create a separate flow for each client file – whatever makes the most sense for your business