Follow / subscribe

Problem Context

• Products may allow users to follow threads, pages, spaces, channels, repositories, issues, pull requests, saved searches, saved views, calendars, authors, topics, or entire workspaces.
• Subscriptions can be created manually by clicking Follow, Subscribe, or Watch, or automatically when the user replies, is mentioned, creates content, owns an object, joins a team, or changes notification settings.
• Delivery may happen through notification center, activity feed, email, push, desktop banners, digests, followed-thread lists, channel badges, or integrations.
• The same word can mean different scopes across products: watching a page differs from watching a space, following a thread differs from following a channel, and subscribing to a saved view differs from saving it.
• Noisy subscriptions often persist longer than the user's original need, so users need narrow scope, visible reasons, and quick cleanup.

Selection Rules

• Choose follow / subscribe when the user is opting into future update delivery from a specific target.
• Use notification center for the retained inbox where delivered subscription updates are triaged, marked read, filtered, and acted on.
• Use activity feed for broad catch-up across many sources; use follow / subscribe to decide which sources or objects are elevated from that stream.
• Use mentions when another person routes attention to the user inside authored content.
• Use threaded discussion when replies and branches need conversation structure; use follow / subscribe to control future reply delivery.
• Use comments when the user is contributing written feedback; subscribing to comments only controls future comment updates.
• Use saved view when the user stores a filtered surface; add follow / subscribe only when future changes to that view trigger delivery.
• Use settings management for global defaults such as email, push, digest, quiet hours, and channel-level notification behavior.
• Use favorites or pinned items for quick return access without update delivery.
• Show whether the subscription target is one item, one thread, one channel, a page and descendants, a space, a repository, a query, or all matching future items.
• Explain automatic follow reasons such as replied, mentioned, author, assigned, owner, or all-new-posts preference.
• Provide unsubscribe, unfollow, mute, reduce frequency, and delivery-channel controls without forcing users to leave the object context.

Required States

• Not following state.
• Following state.
• Watching broader parent scope state.
• Auto-followed because replied, mentioned, authored, assigned, or created state.
• Pending subscription update state.
• Unfollowed or unsubscribed state.
• Muted or delivery disabled state.
• Delivery destination selection state such as Activity feed, notification center, banner, push, email, or digest.
• Event-type selection state such as all updates, replies only, comments, edits, mentions, releases, or status changes.
• Digest or immediate delivery state.
• Permission-limited or inaccessible target state.
• Deleted, archived, completed, closed, or resolved target state.
• Bulk unsubscribe or manage subscriptions state.

Interaction Contract

• Activating Follow, Subscribe, or Watch creates or updates a subscription record for the named target, not merely a visual bookmark.
• The control updates its visible label and selected state only after the product can explain the resulting scope and delivery behavior.
• Users can inspect why they are receiving updates from the object context or notification item, including manual, auto-follow, parent-scope, mention, or preference reasons.
• Unfollow or unsubscribe removes that subscription without deleting the target, comment, notification history, saved view, or favorite.
• Delivery settings separate target scope, event type, channel, frequency, digest, and quiet-mode behavior.
• If access is lost or a target is archived, completed, deleted, or closed, future updates are stopped or downgraded and stale subscriptions become explainable.
• Bulk management pages show enough context to unsubscribe without losing track of which target or scope is being changed.

Implementation Checklist

• Define subscription target types, parent-scope inheritance, event types, delivery channels, frequency, auto-follow triggers, unsubscribe behavior, and cleanup policy.
• Store explicit reason metadata such as manual follow, replied, mentioned, created, assigned, team preference, space watch, repository watch, or saved-view subscription.
• Render per-object state with current label, scope, included events, destination, frequency, and unfollow action.
• Support immediate, digest, muted, paused, and delivery-disabled modes without losing the underlying subscription explanation.
• Synchronize subscriptions with notification center, activity feed, email, push, channel badges, and followed-thread lists.
• Handle permission changes, deleted targets, renamed targets, parent-scope changes, duplicate subscriptions, offline toggles, and bulk unsubscribe safely.
• Test keyboard toggling, menu selection, screen-reader labels, mobile long-press or overflow menus, high-volume subscription lists, digest timing, and cross-device state.

Common Generated-UI Mistakes

• Using Follow as a bookmark with no future update delivery.
• Using Subscribe as a mailing-list opt-in without showing which object or event types are included.
• Hiding Unfollow in global notification settings only.
• Automatically following users without showing why they are receiving updates.
• Treating parent-scope watches and item-level watches as the same state.
• Sending both immediate and digest updates for the same event with no deduplication.
• Keeping subscriptions active after target deletion, archive, permission loss, or issue closure.
• Calling a notification center subscription management page the follow control itself.

Critique Questions

• What exact object, scope, or query does this control subscribe the user to?
• Which future events will produce updates, and where will those updates appear?
• Can the user see why they were automatically subscribed?
• Can the user unfollow, mute, reduce frequency, or change delivery without losing object context?
• How are parent-scope watches, item-level watches, and duplicates resolved?
• What happens when the object is archived, closed, deleted, renamed, or no longer accessible?