We recently did a fair bit of work on multiple multi-value fields and that issue is fixed in the latest and tested by a UK partner and his client:
Fixed in 8.x-5.x - secured with a test and backported to 7.x-5.x - so it will be fixed when we push next releases to drupal.org
If you think that’s awesome 🥳 - you can ...
One way is to do an exclude search.
Create a smart group that has all the people who have borrowed a tool in the last 6 month. Create another smart group that contains everyone.
Under Search => Custom Searches you should find the custom search "Include / Exclude Contacts in a Group / Tag".
Include your group that contains everyone.
Exclude your group ...
We are upgrading from CiviCRM 4.6 to 4.7.17. The Eternal ID is now available for matching to contact records for importing multi-record custom data sets. I just completed a test and the import worked fine and matched using the External ID.
When you create the custom field group, you select Contact, and then click anywhere and you should see a field pop in to view re 'multiple
And once you have added the Fields too, then you should see something like on a contact record. (Grabbed before demo gets flushed)
You can either create custom fields against contact and include them in a profile and using JS play hide and seek with those custom fields or you can create your own fields using buildform hooks and add it to profile form and include JS to hide show.
Multi-Value custom dataset is only available for Contacts and Contact Type custom fields. But i believe it is possible to make it available for Events by creating an extension and adding code using hooks to hack the current behaviour in CiviCRM. I am not sure if anyone has a plan or willing to add this functionality in future version of CiviCRM.
You could set up a Profile as you can specify where people go when they submit it.
therefore you should be able to set Profile A to redirect to Profile B on submission.
I expect this will work 'as is' for logged in users.
There would be a problem if you send someone to Profile A via a link with a checksum as the checksum will 'expire' before they get to ...
It means the custom import inherits some code from the contact import, but in a way that isn't strictly valid (the parameters for the run() method are different than the parent). It would need fixing in core, and looks non-trivial, but it's a warning so the import should still run. Does it still run properly?
You can do this by adding &cid=0 to the end of the donation page URL. E.g. if your page URL is:
Based on your answer, you don't have any multi-value custom data, which is why the drop-down in question is empty. To import custom data, please use the normal import screen, found at Contacts menu > Import Contacts.
I've just tried this out on the demo sites (WordPress and Drupal) CiviCRM 5.5.alpha1 and its still not working. I'll look into reporting it as a bug, but I have found a partial work round (though this isn't what I want).
The problem only occurs with the custom field set using the inline option, so you could use tab or tab with table.
Since this is in theory in-built capability i expected it to be cms agnostic but i don't see it working when i try on demo at http://wpmaster.demo.civicrm.org/civicrm/?page=CiviCRM&q=civicrm/profile/edit&gid=14&reset=1
Which may mean this is a bug that should be added to Jira
I would double-check that the none of the custom data that you are importing exceeds the length constraint set for those custom fields, and raise that constraint if necessary for the long fields.
I believe default is 255 characters for most, and I believe that includes all options for multi-value sets smashed together, not just 255 characters per option.
Unfortunately, at this time (CiviCRM 4.7.13) it's not possible to export multi-record custom fields through the CiviCRM interface.
This question: How do you export a multi record set? suggests an alternate method that may work, but it would take someone experienced at writing custom CiviReports.
The short answer is that it hasn't been built out. It could/would be "achieved through coding", but I don't think it would be done "easily". The issue is that there are a number of places where the assumption is made that there's only one value per field per campaign (or any non-contact entity). You'd need to take care of all of those situations.
If you ...