Aller directement à la fin des métadonnées
Aller au début des métadonnées

Support the use of custom data fields from multi-record data sets in profiles (create/edit/search).

Profile Configuration (Administer > Customize > Profiles

Add / edit profile fields

  • Remove filter which suppresses custom fields from multi-record data sets from appearing in fields dropdown
  • New profile field property / new uf_field DB column: "Include in multi-record listing?" is_multi_summary BOOLEAN
    • Show this field in the form if user selects a custom field from a multi-record custom data set

Profile Search Mode

  • search fields constructed as usual (added to profile, flagged as searchable, optionally included in column)
  • result list displays custom record rows (not distinct contact records). any non-multi-record fields would be replicated for each row. e.g., where custom# is a field in a custom-multi set:
    • John Doe | custom1 | 800-123-4567
    • John Doe | custom4 | 800-123-4567
    • John Doe | custom8 | 800-123-4567
  • view the row details displays multi and non-multi fields
  • form rule: prohibit inclusion of multi-record custom fields from different custom data sets, as we have no way of directly relating them to each other, and thus no way of defining what a single combined row would return.
  • future wishlist: 
    • configurable option to display distinct contacts in search results rather than distinct multi rows. would require form rule prohibiting use of custom multi fields as columns in list view 
    • configurable option to display list of all custom data rows in contact detail view (as a table underneath the non multi fields)

Profile Create Mode

  • data entry is displayed in a simple form, as with current functionality
  • multi and non-multi fields can be combined in the profile and displayed in preferred field order. visually there is no distinction to the user.
  • on submission (create mode / anonymous) non-multi fields are used for contact dedupe matching (as configured in strict dedupe rule). If profile setting is configured for 'Update contact on duplicate match" - then single value fields are updated and multi-value fields trigger insertion of a new custom data row. (this allows a single user to complete the form multiple times, interact with their own record, and generate multiple records for the multi-record fields).

Profile Edit Mode

Profile edit requires the heavy lifting from a UI standpoint as we need to turn the interface into a type of profile record management tool, where the user has the ability to manage both the single-record non-multi fields, and individual rows from the multi-record fields.

  • non-multi fields would be grouped at the top of the page in edit mode, following the existing UI
    • provide help text to the user when configuring the profile to alert them that the field order will not respect non-multi interspersed with multi fields. in other words, we respect the full field order in search and create mode, but in edit mode. the non-multi and multi are separated out (though field order can be preserved within those extracted subsets)
  • multi-fields would be displayed in a table listing and grouped below the non-multi fields
    • the profile config would determine which custom data set fields are used to generate the table listing
      • we could multi-purpose the "results column" option, but I think that is too limiting. also that requires you mark the field for public pages, when this functionality may only be desired for data collection purposes.
      • preferably we add a new option to display the field in the column listing for edit summary view
    • from the listing the user can view/edit/delete the custom data records
    • after clicking view or edit, user is directed to a new modal popup form. after cancel/submit/return they are brought back to the "management" (profile edit) page
    • if delete, trigger a modal popup to confirm and then reload the page
  • below the custom multi listing, include a link to create a new record
    • the new record form triggered from the profile edit screen should only include the multi-record fields – not the multi + non-multi as in the full profile create mode described above. we probably could pass a $_GET or object variable to the profile create view to toggle whether the non-multi fields should be included 
    • create new record needs to respect the "Maximum number of multiple records" option in the custom field set definition. I think we can reasonably only respect that option when working with a logged in user.
  • future wishlist:
    • in the initial implementation we should only allow custom multi data from a single data set (same form rule as for search). in future versions, it would be great to allow as many custom multi as desired, and simply group them in table sets
    •  make "create new record" a configurable option in the profile settings. in some use cases the admin may only want view/edit/delete available



  • Aucun
  1. Feb 22, 2013

    Paul Keogan dit :

    I started testing this feature in the sandbox tonight (4.3. alpha).  I am not sure how far you've gotten. I can update a multi-record field, but I don't see the some of the functionality described above.  What's the bext approach to testing this new feature.

    1. Feb 22, 2013

      using search or edit view is the clearest way to see the implementation. profile/create path ends up looking just like the normal form entry. for example:

  2. Feb 22, 2013

    Paul Keogan dit :

    Thanks Brian,  This functionality will be awesome, thanks for taking in on.  I'll commit to testing it and if you need any help with it, please ping me.  I did add a bug in JIRA last night regarding profiles, I don't know if it is related to this update or not, but the bug appears to be new (at least it was not in 4.2.7)


  3. Mar 07, 2013

    Paul Keogan dit :


    I've done quite a bit of testing an this functionality works well.  Thanks

  4. Mar 25, 2013

    Dave Schafer dit :

    Hi Brian,

    This is a great feature, thanks for the work.

    We're working on back porting this to 4.2.x and have it working (ported the code and selenium tests). 

    We've encountered one issues that I hope you might be able to explain. It appears that the feature is limited to the main contact types (Organization, Household, Individual) and explicitly blocks sub types. 

    Though I'd ask before we go trying to unravel it.


  5. Mar 25, 2013

    Dave -

    The core team actually did the work on this – I developed the specs and managed QA on behalf of my client. 

    I didn't notice that particular restriction, and it wasn't intentionally part of the spec. I'll ask the question of the core team and circle back. 

  6. Mar 26, 2013


    see Kurund's comment here: CRM-10771

    new issue filed here: CRM-12217

  7. Apr 19, 2013

    Paul Keogan dit :

    FYI:  We now have this running on two 4.2x sites, works great.  Thanks

  8. Aug 12, 2015

    Is it possible that this feature lost functionality somewhere?

    I am trying to replicate this functionality on a 4.6.4 Drupal installation, and also tried on the 4.6.7 demo site, and I can't get either to show me anything that looks like this.  When I do an advanced search, select the Contacts I want to update, and go to "Batch Update via Profile", I am only being shown the most recently entered record to edit for each Contact, and when I do edit, it actually creates an additional record rather than updating what exists.  I have checked and unchecked every setting and advanced setting available on the Profile and on the individual fields outlined in the documentation (

    1. Aug 18, 2015

      This feature was never implemented for 'Batch Update via Profile'. The spec above details out the supported use case (Profile-driven search, create and edit). Best to use for further discussion.

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.