A field called \u201cCode\u201d can mean a course code, a cohort label or a credential identifier. If the team importing recipients and the team designing certificates interpret it differently, a successful upload can still produce the wrong document.<\/p>\n
Before creating a custom certificate attribute, define what it means, where its value comes from and where a recipient will see it. Then test a small fictional record from the source file through to the finished credential.<\/p>\n
An attribute supplies a value to a credential. Sertifier’s attribute overview<\/a> distinguishes attributes from the surrounding certificate design. Its custom attribute guide<\/a> documents creating named fields with types such as text, date and number, and matching them during recipient upload.<\/p>\n The field label is an administrative choice; it does not establish that the supplied value is correct. Treat the definition and the value as separate review tasks.<\/p>\n Use a short record for each proposed field. This is a suggested team workflow, not a claim that Sertifier automatically enforces these rules.<\/p>\n Prefer a label such as \u201cWorkshop location\u201d to \u201cLocation\u201d when the program also records a learner’s address or an employer’s office. A field should not silently change meaning between campaigns that reuse it.<\/p>\n Suppose a training team is preparing a fictional Sample A certificate for a laboratory workshop. Its approved source record has these values:<\/p>\nWrite a field definition before opening the designer<\/h2>\n
\n
Work through a fictional example<\/h2>\n