You built a smart field that works: a constituent’s total membership revenue, say, or their most recent visit date. Now you need the same thing with one change: a different date range, a different revenue type, a different program. The natural move is to copy the one you have and tweak it. In Altru, that move usually isn’t there.
Short version: as far as we know, Altru doesn’t offer a copy or “save as” option for smart fields. Each new smart field is built from scratch, starting from a smart field definition and its parameters. Features change, though, so check in your own environment before you take our word for it. Open an existing smart field and look at the available actions, or ask Blackbaud support whether a copy option exists for your version.
Assuming it doesn’t, here’s how to make rebuilding fast and accurate, and how to tell whether you need a second smart field at all.
First, decide whether you really need a duplicate
A lot of “copy this smart field” moments are really “I need to see this number a different way.” Before building a near-twin, ask:
- Can a query filter do the job? If the existing smart field returns lifetime membership revenue and you only need members above a threshold, filter on the smart field value in your query. No new field needed.
- Is the difference a time window? “Giving this fiscal year” versus “giving last fiscal year” really is a different calculation, and that usually does justify a second smart field. A one-time report usually doesn’t. A query against revenue with a date filter may answer it.
- Will anyone use it in six months? Smart fields are shared across the database. Every extra one adds clutter to the field list in queries and makes the next person ask which version is correct.
If you still need it, build it. Just build it from notes, not memory.
Recreating a smart field without drift
The risk with rebuilding by hand isn’t the time. It’s ending up with two fields that look alike but were configured slightly differently, then trusting both. This process keeps the second one honest.
- Open the original and write down everything. Record the smart field definition it was built from, every parameter (revenue types, designations, membership programs, date ranges, whatever that definition asks for), and any value groups or ranges. A screenshot of each screen is fine. The goal is a complete record you can compare against.
- Decide on the one thing that changes. Write it next to your notes. If you find yourself changing three things, you’re building a new field, not a variant, and it deserves its own name and purpose.
- Name it so the difference is obvious. “Membership Revenue – Lifetime” and “Membership Revenue – Last 12 Months” reads better in a field list than “Membership Revenue” and “Membership Revenue 2.” Put the distinguishing part where people will see it.
- Use the description field. Say what it calculates, what makes it different from its sibling, who asked for it, and the date. Future you will be grateful.
- Build it, then process it. Smart field values are calculated by a process, not live. A brand-new smart field won’t return useful values until that process has run. Check that it’s included in whatever schedule your organization uses to keep smart fields current.
Check the copy against the original
Once both fields have processed, prove they behave the way you expect before anyone uses the new one for a report or a mailing:
- Build a constituent query that outputs both smart fields side by side for a handful of records you know well: a long-time member, a lapsed one, someone with no activity.
- Where the one changed parameter shouldn’t matter for a record, the two values should match. If they don’t, something else differs, and your notes from step one will show you what.
- Spot-check one or two values against the constituent’s actual revenue or membership history. A smart field that is wrong in a consistent way is easy to miss.
Keep a simple smart field register
If your team creates smart fields often, a shared spreadsheet saves a lot of rebuilding. One row per smart field: name, definition used, parameters, purpose, owner, date created. When the next variant comes along, you copy the row instead of reverse-engineering the screens. It also makes cleanup possible. You can see which fields nobody has claimed and retire them deliberately.
That register is also the closest thing to a “save as” you’ll get. The configuration lives in a document you can duplicate, and Altru gets one careful rebuild.
Quick answers
Can I export a smart field and import a copy?
We’re not aware of a supported way to do that in Altru. If you need it at scale, ask Blackbaud support what’s possible in your environment before trying anything outside the normal screens.
Can I just edit the original instead?
Only if nothing else depends on it. Queries, reports, and selections that use the field will start returning the new values, sometimes without anyone noticing. When in doubt, build a new one.
