How to : Mass renaming of member codes


I have a requirement to rename 10 000 members codes for 1 specific entity

  • I know it is possible to rename a member manually through the entity interface but I have 10 000 members…
  • Clear and reload does not seems to be the right solution because I have selection on procedure on that entity (+ lots of cubes to export, change the flatfile and reload)

Any idea ? Maybe through REST APIs ?



  • Hi Julien,

    How complicated is the rename that you need to do? Is it simply adding a prefix to an existing number or are the codes going to look completely different?

    For example, are you going from:

    001 to PROD001 or something more complicated than this?

  • Hi Julien,

    You can also try the following:

    1. Create a new entity in the datamodel
    2. Add all the new codes and descriptions to this new entity
    3. Make the new entity the parent of your old one
    4. Relate the members in the old entity to the new entity
    5. Users have an option to view data by old and new codes

    Would this solution work for you?



  • That's a great idea, Zoltan!

  • Hi Julien,

    Is this something that you would be able to elaborate on further? Unless you are looking to change the description of the entities rather than the code, this is a large undertaking due to how much data might already be present in the application.

    You mentioned 10k members for this one entity, how many members are in this entity?

    Would it be better to use a new entity all together? Potentially create a mapping cube between the two entities and run a dataflow to move the data with the mapping cube?

    The data in cubes, is that something that could be reloaded from a source system or would they have to be done more manually?


  • Hi,

    Thanks for your feedback

    Unfortunately, I really need to rename all the members code of 1 entity (10 000 members) because masterdata changes in our source system and we want to align masterdata on all our software.

    Permanent workaround like parent entity are not really an option (too many cubes, procedures, perfs etc)

    The data in cubes cannot be reloaded from a source system because of historical data. Only the current month can be reloaded from the source system.

    The only way to rename member codes is manual ? (no APIs call or edit a file ?)



  • Florian Deutsch
    Florian Deutsch Active Partner
    5 Up Votes First Anniversary Name Dropper First Comment

    What prevents you from performing a full load once, if all historical data is persisted in your data warehouse? Or are you solely using Board without the historical data being present in your warehouse?

  • Hi,

    Datawarehouse contains live data while in Board, we have closing calendar so data is not in sync with source systems.

    I think the main issue is the lack of feature on BOARD related to member code renaming (no APIs or cmd utility to perform mass renaming)

    + the fact that BOARD is not really using member code but internal hidden ID to perform member selection so after a clear and reload of an entity, BOARD will give different internal ID



  • Hi,

    if not too many cube are affected you could temporarily create an entity above your "old" entity with the 1:1 relationship of old and new codes. With the export cube procedure step you now have the option to export both entities (+ rest of course) so you get the mapping in the cube extract. Now this temp-entity is no longer needed and you could clear the original and load the new codes into it with manual created datareader for your earlier exported cubes onto the new code.

    Also, to get the original order of the entity itself you might want to export the entity without any sort settings (= order of entered/loaded master data), map this order to the new codes, clear the entity & reload it with your new codes and "same" order. Please note that this only works if no elements have been manually deleted.

    Maybe this might work for you.

    Kind regards,

  • Hi @Julien CARDON,

    a similar challenge, addressing the reconciliation of identical elements assigned with multiple codes, has been addressed in one of our best practice articles: