create-or-fill-user is LH_Profile_Create_Or_Fill_User_Ability (includes/lh-profile-create-or-fill-user-ability-class.php). It replaced lh-buddypress-add-user/create-user and needs LH User Provisioning, which resolves existing users by email or registered alias (lh_user_provisioning_resolve_user()) and, from 1.3.3, seeds a new user’s BuddyPress last activity from their registration date without ever bumping an existing value. Its profile field schema comes from LH_Profile_Fill_Fields.search-users is LH_Profile_Search_Users_Ability (includes/lh-profile-search-users-ability-class.php). Since 3.8.0 it is the network’s only user-lookup ability. Other plugins extend it with the lh_profile_search_users_input_properties, _result_properties, _restrictions and _results filters: LH Membership adds membership status, and LH Contacts adds a signed short-lived vcard_url (LH Vcard did until LH Contacts replaced it).update-user-profile (3.15.0) is LH_Profile_Update_User_Profile_Ability (includes/lh-profile-update-user-profile-ability-class.php), the overwrite counterpart to create-or-fill-user for corrections such as membership triage fixes. It validates with LH_Profile_Fill_Fields::validate_value() and LH_Profile_Known_As_Field::validate(), then writes through LH_Profile_Field_Saver in overwrite mode with clear_empty. The confirm token is a site transient keyed by the token’s hash and bound to actor, user, site and the exact before/after values, as set-primary-site does. Who may use it mirrors sync-display-name and reuses its return_claimed_roles(): profile fields are network-wide, so promote_users only reaches users unclaimed on every site. Each apply records account.profile_updated in LH Audit Trail (member-visible, retention_days 0), with the lh-tasks task_id captured on wp_ability_normalize_input at priority 5, before lh-tasks strips it. Capabilities are filterable with lh_profile_update_user_profile_return_capability and _return_unrestricted_capability. No member notification, by decision.- Since 3.16.0
update-user-profile takes display_name_from: the display name is built with LH_Profile_Sync_Display_Name_Ability::return_options() from the names as they will be after the change (overrides for first_name, last_name and nickname), never free text, and goes into the same preview, token and audit entry. A display name that followed a changed Known as is recorded too. sync-display-name records its writes through the public LH_Profile_Update_User_Profile_Ability::record_audit(), with the task from take_task_id(), so every display name change by ability is on the audit trail.