Exporting Salsa for CiviCRM » History » Version 49
Jon Goldberg, 10/16/2015 12:29 PM
1 | 24 | Jon Goldberg | {{lastupdated_at}} by {{lastupdated_by}} |
---|---|---|---|
2 | |||
3 | 1 | Jon Goldberg | h1. Exporting Salsa for CiviCRM |
4 | |||
5 | 45 | Jon Goldberg | When logged in as a Manager, go to "Supporter Management" tab, and "Query/Export" will give you a full export of contact data. There's a "Select My Entire List" button. There's also an "include my deleted supporters" checkbox, which you may want to check (but probably not). This will NOT get you groups/tags. |
6 | 1 | Jon Goldberg | |
7 | 41 | Jon Goldberg | *IMPORTANT* - Before you begin - When exporting from Salsa, exporting to screen and exporting to a file yield different formats! Be sure to be consistent, or you'll find that your field names change, your date formats change, etc. *If you're exporting to give data to Palante, please use the scheduled export*. |
8 | 40 | Jon Goldberg | |
9 | 14 | Jon Goldberg | h2. Exporting Data not on the Contact Entity |
10 | 2 | Jon Goldberg | |
11 | 25 | Jon Goldberg | You need to get to custom reports. If you have the Reports tab, great; if not, you can get there by clicking "Supporter Management" tab, then "Built-in Reports", then "Clone and Edit" a report, then select "List Your Custom Reports". Or go straight here: https://hq-org.salsalabs.com/dia/hq/reports/list.jsp?table=report |
12 | 1 | Jon Goldberg | |
13 | 8 | Jon Goldberg | *Important*: When selecting foreign keys (e.g. "Supporter KEY") from the Columns tab, be sure to give a custom label. This will cause the key to display correctly, instead of giving a link to the supporter's record. |
14 | |||
15 | 11 | Jon Goldberg | h3. Groups |
16 | 12 | Jon Goldberg | |
17 | 3 | Jon Goldberg | * Create a new report. |
18 | * Select the type of report you would like to create: Standard report |
||
19 | * Use "Advanced Object Chooser". |
||
20 | 9 | Jon Goldberg | * Report "Supporter Groups", then "Groups". Press "Save". |
21 | 1 | Jon Goldberg | * Select the "Columns" tab and select your columns. I like just "Supporter Key" and "Group Name". |
22 | 7 | Jon Goldberg | * In Conditions, "Group Name" should be "Not Empty". |
23 | 4 | Jon Goldberg | * Save, Run the report. |
24 | * Click the "Export" link. |
||
25 | 1 | Jon Goldberg | |
26 | 11 | Jon Goldberg | h3. Tags |
27 | 12 | Jon Goldberg | |
28 | 5 | Jon Goldberg | * Create a new report. |
29 | * Select the type of report you would like to create: Standard report |
||
30 | * Use "Advanced Object Chooser". |
||
31 | * Report on "Tags", then "Tags Data", then "Database Table". Press "Save". |
||
32 | * Select the "Columns" tab and select your columns. I like just "Tag" and "Table Key". |
||
33 | 1 | Jon Goldberg | ** "Table Key" is the Supporter Key. It's similar to "entity_id" in CiviCRM. |
34 | 7 | Jon Goldberg | * In "Conditions", "Table Name" should equal "supporter". |
35 | 10 | Jon Goldberg | * Add another condition: "Tag.Tag" is "Not Empty". |
36 | 1 | Jon Goldberg | * Save, Run the report. |
37 | * Click the "Export" link. |
||
38 | |||
39 | 11 | Jon Goldberg | h3. Events |
40 | 1 | Jon Goldberg | |
41 | 15 | Jon Goldberg | As above, but no conditions, and report on the "Event" table. If you're only importing legacy events, this is a good list of easy fields to import: |
42 | Event KEY |
||
43 | Reference Name |
||
44 | Event Name |
||
45 | Description |
||
46 | Start |
||
47 | End |
||
48 | Deadline |
||
49 | Maximum Attendees |
||
50 | 46 | Jon Goldberg | Date Created (is a useful proxy when "Start" isn't defined) |
51 | 15 | Jon Goldberg | |
52 | 1 | Jon Goldberg | h3. Participants |
53 | 16 | Jon Goldberg | |
54 | As above. Report on tables "Supporter Event", then "Event". Note that there are a lot of tables that _look_ like "Supporter Event", like "Supporterevent" and "Supporter Events"! |
||
55 | |||
56 | Note that if you're matching on a unique field from "Events", you can just export "Supporter Event" and not the "Event" table. |
||
57 | Here are the fields I exported and what I matched them to: |
||
58 | Supporter KEY external_identifier |
||
59 | Event KEY event_key |
||
60 | Status status |
||
61 | Type role |
||
62 | Date Created register_date |
||
63 | |||
64 | 28 | Jon Goldberg | h3. Recurring Donations |
65 | |||
66 | Export on table "Recurring Donation". Here's the field mapping: |
||
67 | |||
68 | Recurring Donation Key -> trxn_id |
||
69 | Supporter Key -> external_identifier |
||
70 | Transaction date -> create_date |
||
71 | Start Date -> start_date |
||
72 | RPREF -> invoice_id |
||
73 | RESULT (exclude 37, they're tests) |
||
74 | Amount -> amount |
||
75 | Pay Period -> use to remap to frequency_unit and frequency_interval |
||
76 | TERM -> installments |
||
77 | Status(?) |
||
78 | |||
79 | Note that in Salsa, there's no clear-cut way to tell whether a contact's recurring donation is still working or not - "Status" isn't a complete indicator, and thus doesn't cleanly map into Civi. |
||
80 | |||
81 | 27 | Jon Goldberg | h3. Donations |
82 | |||
83 | It's important to link the recurring donations to the donations when exporting if you need to identify the first recurring donation (e.g. to generate thank-you letters if it's a first donation and recurring). |
||
84 | |||
85 | 30 | Jon Goldberg | Under "Conditions", filter by "Supporter KEY is not empty" - when Salsa imports legacy data into their system, sometimes they don't do such a hot job. |
86 | |||
87 | 29 | Jon Goldberg | Export on table "Donation" linked to table "Donate Page". You'll want these fields (more or less): |
88 | 27 | Jon Goldberg | |
89 | Donation.donation KEY(donation) |
||
90 | 1 | Jon Goldberg | Donation.supporter KEY(donation) |
91 | 42 | Jon Goldberg | donate_page.Reference_Name (contribution_page_id) |
92 | Donation.Date_Entered |
||
93 | 27 | Jon Goldberg | Donation.Transaction Date(donation) |
94 | 1 | Jon Goldberg | Donation.amount(donation) |
95 | 43 | Jon Goldberg | Donation.Transaction Type(donation) (financial_type) |
96 | Donation.RESULT(donation) (only 0 and -1 should be accepted, others are tests) |
||
97 | 42 | Jon Goldberg | Donation.Tracking Code(donation) (source) |
98 | Donation.Designation Code(donation) (source - not sure what the differentiation between designation and tracking codes is) |
||
99 | 1 | Jon Goldberg | Donation.In Honor Name(donation) |
100 | Donation.In Honor Email(donation) |
||
101 | 27 | Jon Goldberg | Donation.In Honor Address(donation) |
102 | Recurring donation.Transaction Date(recurring_donation) |
||
103 | 1 | Jon Goldberg | Donation.Order_Info |
104 | 42 | Jon Goldberg | Donation.Form of Payment (payment_instrument) |
105 | 27 | Jon Goldberg | |
106 | 44 | Jon Goldberg | *Special Note:* Salsa seems to keep donations that are tied to supporters that don't exist (that is, the supporter_key on the donation doesn't match anyone in Salsa). I've seen this multiple times; I don't know why this is, but this is normal. |
107 | |||
108 | 19 | Jon Goldberg | h3. Actions |
109 | 17 | Jon Goldberg | |
110 | 19 | Jon Goldberg | Salsa has a separate table for actions, making them structurally comparable to Civi Events. A good match in Civi is the Survey entity, which is used for petitions. |
111 | 1 | Jon Goldberg | |
112 | 19 | Jon Goldberg | Export as above. Report on table "Action". |
113 | 1 | Jon Goldberg | Condition: "Reference Name" is not empty. |
114 | 47 | Jon Goldberg | |
115 | Fields: |
||
116 | Action.action KEY |
||
117 | Action.Reference Name |
||
118 | Action.Date Created |
||
119 | Action.Signatures |
||
120 | Action.Last Modified |
||
121 | Action.Title |
||
122 | Action.Description |
||
123 | |||
124 | 19 | Jon Goldberg | |
125 | *Note*: "Description" is likely to contain HTML that breaks the export. I find it helpful to export it as the last column. |
||
126 | |||
127 | h3. Supporter_Actions |
||
128 | 11 | Jon Goldberg | |
129 | 22 | Jon Goldberg | Export "action" and "supporter_action" and "supporter_action_comment" in that order. |
130 | 23 | Jon Goldberg | Condition: supporter_key IS NOT NULL |
131 | 20 | Jon Goldberg | |
132 | Here's the fields I grabbed with their mapping: |
||
133 | 22 | Jon Goldberg | supporter_action.supporter_key |
134 | 21 | Jon Goldberg | action.Reference Name |
135 | 22 | Jon Goldberg | supporter_action.Date_Created |
136 | 48 | Jon Goldberg | supporter_action_comment.Comment |
137 | 20 | Jon Goldberg | |
138 | 31 | Jon Goldberg | h3. Letter to the Editor |
139 | |||
140 | This isn't a feature CiviCRM has, but it maps reasonably well to an activity when migrating. |
||
141 | * Create a new report. |
||
142 | * Select the type of report you would like to create: Standard report |
||
143 | * Use "Advanced Object Chooser". |
||
144 | 49 | Jon Goldberg | * Report "Supporter Letter", then "Letter". Press "Save". |
145 | 31 | Jon Goldberg | * Select the "Columns" tab and select your columns: |
146 | > Date_Created -> activity_date_time |
||
147 | > supporter_KEY -> external_identifier |
||
148 | > person_media_ID? -> seems important - but I can't find a matching table, and this data doesn't seem to be accessible from Salsa. |
||
149 | > Letter_Subject -> details (concatenated) |
||
150 | > Letter_Content -> details |
||
151 | > Reference_Name -> subject |
||
152 | * Save, Run the report. |
||
153 | * Click the "Export" link. |
||
154 | |||
155 | 11 | Jon Goldberg | h3. Chapters |
156 | 12 | Jon Goldberg | |
157 | 7 | Jon Goldberg | * Create a new report. |
158 | 1 | Jon Goldberg | * Select the type of report you would like to create: Standard report |
159 | 7 | Jon Goldberg | * Use "Advanced Object Chooser". |
160 | 8 | Jon Goldberg | * Report "Supporter Chapter", then "Chapter". Press "Save". |
161 | * Select the "Columns" tab and select your columns. I like just "Supporter KEY" and "Chapter.Name". |
||
162 | * In Conditions, "Chapter.Name" should be "Not Empty". |
||
163 | 5 | Jon Goldberg | * Save, Run the report. |
164 | 1 | Jon Goldberg | * Click the "Export" link. |
165 | |||
166 | 32 | Jon Goldberg | h2. Programmatically creating custom fields in CiviCRM |
167 | |||
168 | To do this, you'll need to create a custom group, custom fields, option groups, and option values. |
||
169 | |||
170 | h3. Custom Field Group |
||
171 | |||
172 | Don't export anything from Salsa - just create this manually, or using my Kettle transform. |
||
173 | |||
174 | h3. Custom Fields, Option Groups, Option Values |
||
175 | |||
176 | 33 | Jon Goldberg | _Custom Columns_ |
177 | * Create a new report. |
||
178 | * Select the type of report you would like to create: Standard report |
||
179 | * Use "Advanced Object Chooser". |
||
180 | * Report "Custom Columns". Press "Save". |
||
181 | * Select the "Columns" tab and select your columns: |
||
182 | 36 | Jon Goldberg | > custom_column_key -> needed to relate to custom_column_options. Store in filter temporarily. |
183 | 34 | Jon Goldberg | > data_table (should = supporter_custom. In theory, we can probably export non-contact custom fields in this same process) |
184 | 33 | Jon Goldberg | > Date_Created -> created_date |
185 | > label -> label |
||
186 | > type -> data_type, html_type (can be bool, enum, text, varchar) |
||
187 | > Description -> help_pre |
||
188 | > Order -> weight |
||
189 | 38 | Jon Goldberg | > Name |
190 | 33 | Jon Goldberg | * Save, Run the report. |
191 | 1 | Jon Goldberg | * Click the "Export" link. |
192 | 37 | Jon Goldberg | * Do NOT import the Salsa name, it'll screw up Civi. |
193 | 1 | Jon Goldberg | |
194 | 35 | Jon Goldberg | _Option Groups_ |
195 | 36 | Jon Goldberg | These will be created automatically when you create custom fields. |
196 | 35 | Jon Goldberg | |
197 | 1 | Jon Goldberg | _Custom Column Options_ |
198 | 33 | Jon Goldberg | * Create a new report. |
199 | * Select the type of report you would like to create: Standard report |
||
200 | * Use "Advanced Object Chooser". |
||
201 | * Report "Custom Column Options". Press "Save". |
||
202 | * Select the "Columns" tab and select your columns: |
||
203 | 1 | Jon Goldberg | > custom_column_KEY -> a lookup field (against civicrm_custom_field.filter to get option_group_id) |
204 | 37 | Jon Goldberg | > custom_column_option_KEY -> value |
205 | > value -> name |
||
206 | 33 | Jon Goldberg | > label -> label |
207 | > isDefault -> is_default |
||
208 | > isDisplayed -> is_active |
||
209 | > _Order -> weight |
||
210 | * Save, Run the report. |
||
211 | * Click the "Export" link. |
||
212 | 7 | Jon Goldberg | |
213 | 1 | Jon Goldberg | h3. Receive_Email field |
214 | |||
215 | 26 | Jon Goldberg | Here's a TSV of how to interpret the "Receive_Email" field. |
216 | |*code*|*meaning*| |
||
217 | |-24|INACTIVE: (5.1.1 User Unknown)| |
||
218 | |-26|INACTIVE: Address contains RFC spec. invalid characters / is improperly formatted| |
||
219 | |-3|INACTIVE: UNSUBSCRIBED (actively unsubscribed by user)| |
||
220 | |-30|INACTIVE (Reported as Spam): Other Blacklist (BLACKLIST)| |
||
221 | |-32|(Unknown Status)| |
||
222 | |-35|INACTIVE (Reported as Spam): Outblaze| |
||
223 | |-4|(Unknown Status)| |
||
224 | |-42|INACTIVE (Recipient Initiated Spam Report): MSN/Hotmail/WebTV| |
||
225 | |-44|INACTIVE (Recipient Initiated Spam Report): UNTI (Juno/NetZero/FreeServers)| |
||
226 | |-45|INACTIVE (Recipient Initiated Spam Report): Yahoo| |
||
227 | |-46|INACTIVE (Recipient Initiated Spam Report): Comcast.net| |
||
228 | |-47|INACTIVE (Recipient Initiated Spam Report): AOL| |
||
229 | |-48|INACTIVE (Recipient Initiated Spam Report): RoadRunner| |
||
230 | |-50|ISP Specific Bounces: AIM.com Unactivated account| |
||
231 | |-51|INACTIVE (Recipient Initiated Spam Report): Excite| |
||
232 | |-52|INACTIVE (Reported as Spam): Earthlink| |
||
233 | |-53|(Unknown Status)| |
||
234 | |-54|(Unknown Status)| |
||
235 | |-60|Bad Address/Expired address, etc (n.b.: These addresses are all @democracyinaction.org)| |
||
236 | |-9|INACTIVE: DEATH (supporter has died)| |
||
237 | |0|0 - Inactive or Unknown(not subscribed)| |
||
238 | |1|1 - Imported or unknown (subscribed)| |
||
239 | |10|ACTIVE: CONFIRMED (Double opt-in)| |
||
240 | 1 | Jon Goldberg | |3|ACTIVE: CLIENT (Client has directly signed up)| |