Enter your enhancement requests or ideas for any of the components of the Aprimo SAAS platform, or vote for your preferred feature requests below.
For more information on how to use this forum: Aprimo Voice How-to-Guide
We are seeing frequent use case to have a reference number type of field (numeric EA) which would get a unique number as default value.
Use case: Marketing department needs a new brochure and starts an appropriate project. They have a reference number EA on the project which represents that particular creative piece. Therefore it needs to be incremented value but it also needs to be unique for that particular creative piece. When the brochure is first created (version 1, revision 1), we would like to be able to use system feature to generate unique reference number (increment of previous reference number). Once that creative is built and project finished, we will need to update revision/version later in the future. When starting a project to update that piece of creative to new version/revision, we would overwrite the reference number default generated value with the original reference number for that particular creative piece so that all versions/revisions of the same piece would be tied with the same reference number.
This can be customized, but it is a use case in practically every marketing department, so it would be good for Marketing Productivity to have the feature of generating unique incremented numbers for this type of use case. Generator should take into the account EA length limitation and generate number with leading zeros.
One of line of Business more focused on content management using workflows. So requirement demands more number of EAs in Activity, Project and Task EAs.
So We want to increase the Extended Attribute limit.
The ability to generally alphabetize lists but were told to break out the requests and enter only the most critical. We have the ability to manually alphabetize the teams/list and that saves, however there is not the ability to have the list alphabetize.
For example, when adding Activity Type Statuses within Activity Types, we learned that you had to enter them in the order of appearance. This is an area where the alphabetize feature would be helpful and save a lot of time.
In addition, we feel it would be helpful to have the “Role” and names with the “Users/Groups” in the Master Team Lists be alphabetizable as well to make it easier for us to double check the names included (see example creative development master team list with names not alphabetized). The roles and names within the users/ groups do display alphabetically for users on the Activity Roles tab, and we would like it to be the same representation of the site look for admins.
In order to aid in identifying which extended attribute is used for what purpose, it would be helpful to have a Description field on the extended attribute page.
Additionally, to aid in the auditing of Extended Attributes, it would be helpful to include the Last Modified information on the EA details page.
Use Case for Description: Sometimes we have extended attributes with similar or same names but with minor changes for entirely different processes or process steps. In such cases, a description would be helpful to identify purpose of that attribute.
Use Case for Last Modified: At times we need to audit our extended attributes to ensure they are being utilized. When an EA is obsolete, it can be re-used or maybe removed. When looking at EA Usage, it would be helpful to be able to compare Create Date to the EA usage to know of an “old” EA is not being used. If an EA does not have much usage, but is newly-created, it should not be archived. Another use case is if we have an issue with a workflow due to an EA change. With Last Modified info, we can find out when the EA was modified and by which user.
These would be low-impact, high value enhancements. It would be a positive impact on most SaaS users, or a neutral impact to those who would not need the fields. Additionally, having these fields on the EA details page is consistent with other objects in the application.
Here is a mockup of an Extended Attribute Details Page with these fields:
Custom Unique Identifiers for Activities & Projects - Setup by Admin for Consistent Naming Conventions
Almost every firm utilizes some sort of unique identifier to associate with project or piece of collateral. Currently, Aprimo user’s only option is to create a custom EA with no restrictions on a required format for the input value other than character length. This makes it extremely hard to have consistency with the unique identifier structure because the system doesn’t require that the structure is upheld. Additionally, because the users can input anything they want, it causes duplication of historical identifiers which causes lots of downstream issues when we try to apply it to other systems.
Having the functionality to create firm specific custom unique identifiers will create a huge value add for Aprimo as the system of record. It will strengthen customer's dependence on the system to initiate projects and act as a central hub for connections to other systems.
A system admin can configure a specific EA to generate a unique identifier for each new project through an EA configuration setting. You can configure the settings so that when a new project is created, it will generate a unique identifier for the new project based on the naming properties you configured.
Configure a Unique Identifier:
On the EA settings page, click make a unique identifier.
- On the EA details page, in the Name field, specify a name for the unique identifier you want to create. For example, if the unique identifier is going to be used by the Finance Department for high risk projects , you could enter ** Finance Dept (High Risk) **.
- In the Description field, type a description of the u. For example, Use this unique identifier to create high-risk projects for Finance.
- In the Project ID section, you need to enter information that will be used to create a unique Project ID for your projects that are created through the unique identifier template:
- In the Prefix field, you can enter characters that will be at the start of each generated Project ID. For example, you may want the Project ID for projects created through the Finance Department EPT to begin with FIN_. This field is optional.
- In the Starting Number field, enter a number that will serve as a starting point for Project IDs that are going to be generated for this unique identifier. For example, enter 10001 if you want the first Project ID to be 10001. This field is required.
- In the Postfix field, you can enter characters that can be used to append your Project IDs that are generated by this unique identifier. For example, if the unique identifier is used to create only high-risk projects for the Finance department, you could enter _HR. This field is optional.
- In the Minimum Digit Padding field, enter a number of digits that you want to have for newly generated Project IDs. For example, if you enter 3 and have a Starting Number of 1, then the first three Project IDs that will be generated are 001, 002, and 003. If you enter 5 with a Starting Number of 1, the first three Project IDs that will be generated are 00001, 00002, and 00003.
For example, with the sample settings used in the procedure above, the Project IDs generated through the Finance Dept (High Risk) unique identifier will be:
For larger organizations, it is a good idea for the Project admins or PMO to agree upon a Project ID naming convention and a numeric range to ensure uniqueness. Additionally, it is also a good idea to document the unique identifier settings for reference. For example:
Other best practices to consider:
It is important that you come up with a naming convention on how you want to segment your Project IDs before starting the configuration of your unique identifiers to ensure uniqueness across different unique identifiers.
A Project ID can be edited if it is added to a Project Detail page. You can use this approach to perform ad-hoc edits of the Project ID value if needed. As always, ensure that there is a standardized naming convention in place to ensure uniqueness of your Project IDs if you need to make ad-hoc changes.
We have a Client who would like to rename the "Aprimo DAM" label in the side bar in MO to their own name for the DAM. We've been told this is not currently possible. It would be great to be able to do this for branding purposes. Thank you!
I would like to see a function that allows an Admin to 'Duplicate' a User Group. As part of the copy they should be forced to change the Name and Description. This would help make configuration and setup more efficient given the extent to which you can configure the DAM permissions.
Ability to relabel base Activity date fields (Activity Begin Date/End Date/Project Anchor Date) (VSTS 149448)
The ability to relabel the base Activity date fields would potentially allow us to remove additional date EAs that we have created and improve user experience by eliminating our request for the entry of duplicate dates. This terminology request would be similar to what has already been done for the base “Administrator” field, which we have renamed to Activity Manager. A Business Case example is today, we ask users to input the same date for the base Activity End Date and the Activity Extended Attribute we’ve created called Out of Market Date. If we could relabel End Date to Out of Market Date, we could potentially remove the need for the separate Out of Market Date EA.
|We currently have over 100 activity type statuses that are no longer needed. It has become unmanageable and cumbersome for reporting. Statuses will be consolidated into a single activity level EA. For historical purposes we need to retain the status data (via reporting) without the statuses being visible to the end user. Today that is impossible given that we only have the option to delete statuses.
Business Impact: Retain historical data and follow best practice standards of "inactivating" vs. "deleting".
Justification: It's best practice to inactivate objects vs. delete them; End Users would potentially be using out dated statuses where they are not supposed to; Old statuses may cause confusion. The only work around we have at the moment is including "zzz" at the beginning of each status.
Desired Feature: Allow the inactivation of Activity Type Statuses not just Delete
Customer support service by UserEcho