Zulu Limitations

From 360Works Product Documentation Wiki
Jump to navigation Jump to search
Zulu  
Getting Setup with Zulu: InstallingInstalling as ServletInstalling the Plugin VersionZulu Google SetupIntegrating your file • ‎Zulu Sync • ‎Serving the Sample FileRegistrationInstalling Zulu Manually
About Zulu The big pictureLimitationsRequirementsDifferences between servlet and pluginHostingSecurity
Troubleshooting TroubleshootingTesting ConfigurationsUmlautsURLs Used By ZuluUpdatingLogs
Google Sync with Google • ‎Sharing a Google CalendarGoogle ContactsGoogle ResetAppointment Slots
Calendars Repeating EventsDate Ranges • ‎Read Only CalendarsDeleting EventsInvitationsSwitching CalendarsMultiple CalendarsPropertiesSee it in iCalMy site
Contacts Contact GroupsContacts IntegrationsRelated Contact FieldsAddress BookZulu Phone Fax Email
Does Zulu work with... AndroidBlackberryMultiple MachinesOutlookMobileMeiPhone
Extra Credit Adding FieldsTime ZonesDuplicating RecordsCalc FieldsAccess PrivledgesRefreshFilteringPost Editing ScriptsAlarms and notifications

What are the iCal limitations of Zulu?

iCal is an elaborate and complicated specification and while Zulu understands and respects most of it, there are a number of things Zulu does not (yet) support:

  • Alarms are almost fully supported but there are some differences between events created in iCal and those created in FileMaker. Learn more here: alarms and notifications.
  • Time Zones are also handled pretty well though you can not create a record in FileMaker and specify it to be from a different timezone. All records created in FileMaker are tagged with the server's time zone. Learn more about this and read a couple examples here.
  • Network We have encountered situations where Google account pairings and iCal traffic are being prevented by Network Proxies/Firewalls. As there are no errors being generated by Zulu when this occurs, the issue can be difficult to track down, and depending on your network, may not be resolvable. We strongly recommend testing our demo and sample file on your production network to avoid any surprises when going to deploy.
  • Invitations don't work great now, but they are on our roadmap. Currently, invitations dragged into iCal will become FileMaker records, though the "invite" information is not mapped to FileMaker fields. That's good. Events created in FileMaker can't contain invite information until brought into iCal where invitations can then be requested from them. That's OK. Events created in iCal can not contain invite information (you can not be the organizer of an invitation-event in iCal). That is kind of a drag, but will be fixed soon.
  • Repeating Events created in iCal are not translated into repeating events in FileMaker. If your FileMaker solution creates repeating events as distinct events in their own right (as SeedCode Calendar does) then those individual events are sent correctly to iCal. If you need events created in iCal to have their repetitions translated into repeating FileMaker records, get in touch. We have some custom techniques that can make this happen for you.
  • Free Busy is not mapped in FileMaker so you can't mark records in FileMaker as free or busy. Once marked this way in iCal, however, that attribute will persist FileMaker edits. This is true for most unmapped features in iCal: once added to an event in iCal, the attribute will persist through subsequent edits in FileMaker. Real free-busy support is on the roadmap.
  • Switching Calendars - there are some interesting issues with moving an event from one calendar to another, though this generally works great when doing it within one filtered database (such as when color coding by status). Read up on this here: switching calendars.
  • ToDos - to do items are not supported.

Google Limitations

  • Multiple Accounts You can only sync a a single Google account to one FileMaker account. If you try to pair the same Google account with multiple Filemaker accounts, this will return an error. The same FileMaker account can be synced to multiple Google accounts, however, so this is not really a problem.
  • Switching Calendars Changing an event's calendar (switching calendars) in Google is different than doing it in iCal. In iCal the filter field is simply changed for the event record. No problem. When an event's calendar is changed in Google Calendar, however, the event is tagged as "deleted" (a 1 is placed in the deleted field) and a new event record is created. This can be a problem as fields Google doesn't know about are not preserved when the new record is created. Now the old record is still there, but it is tagged as deleted, and there is no relationship between the old and new record since the new record gets a new Google uuid.
  • For now, our recommendation is to instruct users not to change an event's calendar in Google. But we hope to fix this eventually.
  • Date Range Gates Although these work with ICal, they do not work with the Google Sync. You can limit the events considered by Google by using the zulu_DELETED field if needed.
  • Network We have encountered situations where Google account pairings and iCal traffic are being prevented by Network Proxies/Firewalls. As there are no errors being generated by Zulu when this occurs, the issue can be difficult to track down, and depending on your network, may not be resolvable. We strongly recommend testing our demo and sample file on your production network to avoid any surprises when going to deploy.
  • Editing Filters When adding filters to calendars and, in some cases, when adding calendars, the sync to Google Calendar can take a little longer. This is because Google deletes the events from one calendar and adds them to another. This will show up on Zulu's synch log-- if you're syncing manually--as a lot of deleted events. Don't worry, Zulu is not deleting your FileMaker records, it is only reflecting what Google has done as it moves events from on calendar to another.
  • More than One File You can only sync one calendar file and/or one contact file to Google for each installation of Zulu. Another way to say this is that your calendar mapping and contact mappings can be in different files, but you can only map one calendar file and one contact file in each instance of Zulu. So if you have multiple files, add table occurrences for them to a single file, creating additional Field Mapping layouts and ZuluCalendarList records as necessary so that all your calendar syncs are coming from a single file, though the data may be in many files.
  • File Name Zulu works through FileMaker Server's XML Custom Web Publishing, so spaces are not supported in the file name. You can add your table occurrence references to another file, like our sample one, and publish from there if you don't want to change your file name.
  • Alarm Types If you want to create alarms in FileMaker and have them sync to Google, the only alarm type that currently works is "EMAIL". For other alarm types there is a vocabulary mismatch between what Google does and the iCal spec so we're hoping to add a translation for this and should have that in future builds of Zulu.
  • Calendar Visibility (this was fixed in version 1.247) You can not currently restrict the visibility of a calendar using access privileges as you can on the iCal side. Restricting the visibility of events works just fine. We hope to fix this in a future build of Zulu.

Note: Zulu's Contact Sync is Back in Beta

Regretfully, we've just never been able to get the contact sync in Zulu to be reliable with Google Contacts. Some of this is that Google Contacts is changing and some if that contacts are inherently more complicated than calendar events (the calendar sync in Zulu is rock solid). So until we can get this rock solid we're demoting the contact sync to Beta and no longer supporting it.

We'll continue playing with this here but won't be able to help customers try and get it working: it just isn't reliable enough. At this point we don't have an ETA as to when this feature may be available again, if ever. Believe me, we wanted this to work as bad as you did. Dec 27, 2012.


  • Related Contact Fields Even though FileMaker can make use of related records for phones, emails and addresses, Google can not. There is just a single Contact record in Google, so related information in FileMaker is written to the single Contact record in Google, and in the process any additional information in the related records is lost. To deal with this, Zulu needs to delete and rewrite the related records in FileMaker if they are edited in Google. Since they are being rewritten, any information not stored in one of the Google fields will be lost. This includes the primary key of the related record, and can present some limitations for certain data models.
  • Contact Phone Numbers Google can only sync a subset of phone, fax, and email information about a contact. From Google's FAQ: "The iOS device can synchronize up to 3 email addresses. Phone number synchronization is limited to 2 Home numbers, 1 Home Fax, 1 Mobile, 1 Pager, 3 Work (one will be labeled 'Company Main') and one Work Fax number." Limit your labels to match the Exchange rules and they should synchronize, although you may need to experiment with the order. Leaving them blank in FileMaker and allowing Exchange / Google / Zulu to assign them works as well.
  • Country Codes Google only supports two digit Country Codes in Contact address information. Please make sure you map a field with these codes rather than the Country name. Attempting to sync with a full Country name will cause a syncing error. Supported Country Codes
  • Contact Sync from iPhone can be slow When you make changes to a contact record on your iPhone it can take a while before that edit is seen in Google Contacts. This isn't something Zulu controls, of course: as soon as the edit makes it to Google Contacts, Zulu will pickup that edit and send it to FileMaker (if you have Zulu sync running automatically). So to trouble shoot things, check Google Contacts to make sure it has received the edits from you iPhone before wondering why edits haven't made it to FileMaker.