IFTTT is an automation service that passes an event from one connected service to an action in another. Each automation is called an Applet. A weather change can start a notification, a new calendar event can create a message, or a button in the mobile app can control a connected device. IFTTT does not replace the connected apps or move their complete accounts into one place. It waits for defined trigger data, fills action fields with selected values, and asks the destination service to perform the result.
Trigger starts the chain
An Applet begins with one trigger. The trigger describes a new event, not a search through everything that happened before the Applet existed. After the user enables an Applet, it responds to later trigger events. Old photos, posts, or sensor readings do not automatically run through the new connection.
Some services send events to IFTTT quickly, while others require periodic checks. A trigger can therefore arrive later than the moment visible in the source app. An automation for archiving or logging can tolerate that delay; an alarm or safety response should not rely on a cloud Applet as its only path.
Ingredients carry values
Trigger data appears as ingredients that action fields can reuse. A post title can become a message title, while its URL can fill a link field. Choosing the wrong ingredient can create an empty filename, broken image, or message that contains the wrong value. The Applet editor shows which ingredients belong to its trigger and queries, but it cannot infer what each destination field means.
Published Applets act as premade arrangements. Connecting one still requires authorization and may ask for a folder, playlist, device, location, or account. A published title describes the intended result; it does not guarantee that the selected account contains the named destination.
Conditions change the path
Advanced Applets can request extra data through queries, skip or modify actions through filter logic, pause through a delay, and run more than one action. Execution follows a fixed order: trigger, queries, filter logic, delay, then actions. This matters when a condition uses current data but the action waits, because the world may change during the delay.
Queries, filter logic, and multiple actions depend on the account plan. Delays remain available more broadly and can postpone the action for a limited period. A workflow that needs a pause between two actions may require separate linked Applets rather than one delay inserted in the middle.
Connections can expire
Each service connection grants IFTTT permission to read trigger data or request actions. Password changes, expired permission, or revoked access can stop the Applets that depend on it. Reconnecting the service usually restores authorization. Removing it has wider consequences: created Applets may move to an archive, while enabled published Applets can disappear from the account and need a new connection later.
Activity explains failures
The IFTTT Activity feed shows recent runs, failures, skipped actions, and connection changes. A skipped entry may mean filter conditions rejected the event, repeated action attempts failed, or a service paused. A failed entry can point to expired authorization, a service limit, or invalid action data.
The feed keeps only a short recent window and a limited number of entries. It also labels a multi-action Applet as ran when at least one action succeeded, even if another failed. Troubleshooting therefore requires opening the run details rather than accepting the top-level status. For important records, the destination itself should confirm that the expected object arrived.