Connect the approved library, give people a tool with permitted edits, then check the finished output before delivery. This example uses an event card to show where source governance, creative constraints and final review apply. Lolly makes the file; Lolly Work supplies the connected catalog and governed shared services.
The example is a sequence to run with your own assets, not a claim that every source supports every check. Use the source directory to select an implemented connector.
Prepare the event card
You need a permitted event image and logo, your design system, a Lolly tool for the card and a Work instance if the catalog or delivery is shared. A template owner decides which fields may change, such as the event title, date and image. Legal copy and other protected content need explicit constraints and review.
Build the layout in Design and use Share with rules, or choose an existing tool. Test the tool with long titles, missing images and the actual fonts before giving it to the team.
1. Expose the right sources
The library administrator connects a narrow folder or section, previews its mapping and configures the intended groups. Use upstream approval filtering only where the source provides the expected signal. Confirm original bytes and availability fields on the real tenant.
Run the same selection as an allowed member and an excluded member. A shared provider credential can see more than either person should see, so its successful authentication does not establish correct member access. Use Lolly with your existing DAM explains that boundary.
2. Choose the image and make a variant
The marketer opens the event tool, selects the intended original or supported representation and fills in the permitted fields. Keep the selected file identity when an asset has several attachments. A thumbnail is not a substitute for an original needed by production.
Check that the selected asset is permitted for the intended audience and use. A DAM's approved flag does not establish all licence conditions. Creative rights and credits explains recorded evidence, obligations and credit delivery.
3. Produce the required sizes
Make the first card and check its copy and layout. If the tool supports the needed variants, reuse the tool for each size or use Batch for rows of inputs. Keep protected copy and data fixed while changing permitted layout choices.
Record the output requirements before checking the file. Optional production checks can measure supported facts such as dimensions, exact text or differences against a reference. An unchecked fact is not a pass, and those measurements do not replace creative or rights review.
4. Review the file that will leave
Decide whether ordinary local export or an organisation delivery is the required path. A local export does not automatically acquire Work approval. For a supported organisation destination with a chain, Work stages exact bytes and routes that delivery for review. Approval of a source is separate from approval of this staged file.
Check the actual configuration with Approvals and Organisation delivery destinations. Do not promise an approval-controlled release for export paths that do not enforce one.
5. Deliver and rehearse a change
Send to the configured destination and inspect the receipt. Confirm byte readback where the adapter supports it; receiving an upload acknowledgement alone does not prove publication or unchanged bytes.
Then change or withdraw a source upstream. Refresh the catalog and test listings, previews and new original reads. Record the observed delay and what happens to existing designs. Previously downloaded copies remain a separate responsibility.
Keep a short acceptance record
Record the tested source and file, tool and software revisions, allowed and refused users, output requirements, review decision and delivery result. Keep credentials and private source files out of public evidence. SUSE's Brandfolder experience adds the administrator adoption perspective to this technical sequence.