Sure thing. I’m not sure which parts you’re familiar with and which parts you aren’t, so I’ll just start at the beginning. Apologies if any of it is obvious or repetitive!
Facebook, like many software platforms, provides access to APIs and services through developer applications, which get created at https://developers.facebook.com. Once an app has been created, you can add a range of different “products”, such as OAuth login, messenger access, web payments, analytics, etc.
In n8n, the facebook trigger node is concerned with the “Webhooks” product. As the name implies, webhooks will cause the app to call an arbitrary http endpoint with data when certain events happen within a facebook account, such as new timeline posts, changes to profile pictures, chat sessions, billing transactions, etc. But, in order to get notified about a particular type of data, you have to subscribe to it.
This subscription process has two parts: first you subscribe to an object, and then second you select which fields of that object you want to be notified about. The n8n facebook trigger node handles the first part but not the second.
When creating a new facebook trigger node, you have to specify which object you would like to subscribe to. There are, at present, 8 different objects, including “page”, “user”, “application”, etc. When the node is activated, the object subscription is created, and when the node is deactivated, it is destroyed. That all works as it should.
The problem is that, in addition to object subscriptions, it is also necessary to subscribe to fields. The “page” object, for example, has several dozen different fields, including “bio”, “birthday”, “feed”, “name”, “phone”, “leadgen”, etc. Each field represents a particular data structure for which change notifications can be created. If you subscribe to “feed”, for example, your webhook endpoint will get called when a new post is made to the page. If you subscribe to “leadgen”, it will get called when somebody fills out a leadgen form. When a new object subscription is created, it won’t do anything unless at least some of these fields are also subscribed to.
At present, when a new object subscription is created, no field subscriptions are made. They must be made at the facebook application developer console. That wouldn’t be a huge problem if those field subscriptions were permanent, but they aren’t. When the trigger node is deactivated for any reason, the object subscription is destroyed. When it gets activated again the subscription is created without any fields selected. The facebook trigger node does not at present “remember” which fields an application subscribes to. It only remembers the object.
I’ve described a somewhat clumsy solution to this problem above, but a better solution would be for the facebook trigger node to specify not just the subscription object but also the subscription field(s).