Import from the Portal

Studio roles: "Owner" and "Administrator", and Studio users with the permission set "Voucher manager".

When a Community Portal starts redeeming through the Studio, its Benefits' codes and partner addresses move here once. The Portal's redemption setup report writes them to one file; the import turns it into partners, voucher offers and voucher pools, and gives you a mapping the Portal links its Benefits by.

The file holds every live voucher code. Hand it over directly, never by email or chat, import it, and delete it afterwards. The Studio reads it and stores nothing of the file itself.

Import the file

1. Under "Voucher offers", choose "Import from the Portal".
2. Choose the redemption setup file (JSON). A file of another format, another version or with an error is refused, with the place of each error. An anonymized file, the one the report writes for tests, is never taken here.
3. Check the preview. Nothing is stored yet. It counts the new and existing partners, the new voucher offers, those imported already, the conflicts and the Benefits not imported, and the new voucher pools. The tables list each partner with its name and redemption address, and each Benefit's voucher offer with its partner, its codes masked, what the import does with it and any notes. A voucher offer imported already shows its status and partner as they are now.
4. Choose "Import". When it is done, choose "Download the mapping" and keep the file for the Portal's link migration. It holds ids only.
5. Fill the voucher pools listed under "Voucher pools to fill" with your partners' code lists: each link opens the pool's import page.

You can run the import as often as you like: a second run creates nothing that exists already, and gives the same mapping. If an import stops halfway, run it again to create the rest. The preview and the import must see the same file and the same vouchers; if anything changed in between, you are asked to check the preview again.

How the import decides

• Partners: one partner per redemption address of the voucher offers the import creates, the Benefit's own address, else the Portal's fallback address. A partner of your organisation with that address is used. A new partner is named after the title of its first Benefit, never after its address, which members could otherwise see; rename it afterwards. A Benefit that is not imported gets no partner.
• No address: a Benefit without any redemption address gets a voucher offer without a partner. Its email redemptions go to the default redemption address of the voucher settings.
• Voucher offers: one per Benefit, named by its title, with the redemption limit unlimited. A published Benefit's offer is "Active". A Benefit that is not published gets a "Draft" offer: activate it once the Benefit is published.
• Codes: what members are given today wins. A Benefit that uses a static code keeps it: new customers get its code, existing customers their own code where the Benefit gives them one, else the code for new customers. Only a customer kind given no code today draws from a voucher pool, and the offer gets an empty voucher pool for it. A Benefit with no code at all is not imported: create its offer, and its partner if needed, by hand.
• Never an overwrite: an offer imported already is never changed. If its codes differ from the file, for example because you changed them in the Studio, it is shown as a "Conflict". The mapping still names that offer.

The notes say where to look: a Benefit with an unpublished draft that changes its redemption (the file holds the published version), a code that is typed but not in use, or a voucher pool with the limit unlimited, where you may want to set a limit.

Every partner, voucher offer and voucher pool the import creates is recorded with who imported it and when.