This article covers material I presented during an Anaplan User Group session in 2021. The module snapshots are from prior to my transition to the Anaplan UX for visualization outputs.
As someone who started off as an Anaplan implementation consultant and then moved on to manage a tenured Anaplan deployment within a corporation, the perspective and priorities are different for each role when it comes to sustainability.
As a consultant, you’re typically building out an Anaplan use case from scratch and have a clear go-live date detailed in the statement of work. Once the project is finished, you move on to the next project.
After shifting to an internal manager of Anaplan, those clear goal posts go away and it becomes harder to track progress and milestones. While it’s possible to get all users trained and processes documented at a given point in time, the likelihood is that many users will churn and processes will also change.
For these reasons, building a model with sustainability in mind requires a different mindset and a higher standard of delivery to promote the transparency and transferability of your work. Below are recommendations for internal Anaplan managers to help promote the long-term sustainability of your Anaplan deployment.
1. Development tags
If you poke around a tenured Anaplan deployment, even ones with the strictest controls, it’s common to see line items with the “DEV_” or “TEST_” prefix within the production environment. While having these in your model presents an obvious risk, there are a number of reasons why this happens:
Convenience factor. Creating additional DEV or TEST line items is one of the easiest ways to perform scenario analysis, without ever needing to touch lists or versions. And in most cases, you’ll immediately be able to compare your new DEV line items to the current live calculations. Additionally, the prefix approach is accommodating in that you can add them to almost any component of Anaplan (line items, lists, list items, saved views, modules, subsets, import actions, etc.).
Ability to isolate . Assuming you have an experienced Anaplanner on your team who is familiar with your model and use case, it’s not difficult to isolate the impact of these tags by adding a glaring all-caps prefix to the DEV items and making sure none of the production line items reference the new DEV items.
Anaplan’s value proposition. Part of Anaplan’s core value proposition is being able to provide the flexibility and immediacy of Excel, while still maintaining the higher standards of an Enterprise Resource Planning tool. Assuming you have a way to manage the overall process, leveraging development tags is a way to achieve that balance.
I know some only allow development tags in a DEV or Test model separate from production. Consider allowing development tags in your model only if you manage and track them closely. You can do so with a simple list and module.
Other items to keep in mind around development tag management:
Establish rules and guidelines. If you have certain modules or lists where you absolutely do not want development tags to be created, confirm these restrictions with your team. For example, you could have a very large module in terms of cell count, where the addition of “DEV_” line items would significantly increase the overall size of your model.
Tag owners. Ensure that each development tag has a specific owner so that you have someone to follow up with to track its progress, identify blockers, and push the final changes through to production.
Prioritize clean up. During a busy planning cycle, it’s very easy to overlook this step. But we all know that having extraneous “DEV_” line items in your model represents a risk to your Anaplan deployment long term, even if they are not directly impacting production line items. Make sure you track your development tags to completion and remove them from your model when done.
2. Restore points with baselines
Regardless of how experienced you are with Anaplan, at some point during your model building career you’ll run into a situation where it’s difficult to fully understand the downstream impact of a proposed change. This can come from inheriting a model from another person, working within an intense planning cycle where you don’t have significant time allocated for testing, or simply being asked to make a complex structural change to a tenured model.
Leveraging restore points with baselines is a simple way to assess the impact of changes you’ve made to the model, while also providing a safety net of an “undo button” (the restore point) if you notice unintended outcomes after your changes.
Creating a restore point interface is simple:
Restore point input. Create an input cell for your restore point that is lengthy and contains all the context you want to capture. With a single lengthy input, it’s much easier to find that specific change in the model history if and when you need to restore the model.
Context values. You should have the context values calculate automatically based on the restore point input, rather than having multiple cell inputs. This is done through simple text formulas.
Baseline references. Choose references that cover all areas that could possibly be impacted by your changes. Immediately after creating the restore point, hardcode these baseline reference values.
Once you have these elements in place, it’s simple to create your restore point, snapshot your baseline values, make your proposed change, and check the interface for variances.
Two final notes about restore points:
Last resort. Performing a model restore in your production environment isn’t something you should take lightly. If you have a large number of contributors in various time zones, performing a model restore could potentially erase several hours of work from different teams. While I like having restore points easily identifiable in my change history, I view actually “restoring the model” as more of a last resort and will try all other approaches first. If you do end up in a situation where the model restore is necessary, clearly communicate the implications with your team.
DEV model. A simple way to remove the constraints of restoring your model is to create a DEV copy of your model, ideally in a DEV workspace that your regular model contributors don’t have access to. Once there, you’ll have more freedom to make changes and even restore your model without affecting the work of your model contributors.
3. Use custom versioning lists
Versions is one of the core functionalities that we learn about during our initial ramp-up process. I remember how heavily it was emphasized during my first demo of the tool. Despite its prominence as an Anaplan feature, best practice guidance has shifted away from using Anaplan’s base “versions” functionality and instead using “custom versioning lists.” Essentially, you are migrating all your versioning needs away from the built-in functionality over to a set of lists. From the perspective of sustainability, there are several reasons to do this:
Model transparency. Most models will eventually need to leverage more than one use type of “versions” to cover the scope of the use case. In the example shown, in addition to the primary planning calculations, we also need versioning capabilities for the top-down target and forecast scenarios.
Model relevance. When you begin the build of a model, it’s generally clear what Anaplan’s generic “versions” functionality should apply to. In the example above, it would be our primary plan. However, over time as the model grows and evolves, there is a likelihood that this default version will apply to fewer and fewer modules. For an aged model, it can be confusing to new users to see the core versions functionality only applied to a small set of modules.
Model simplicity. I’ve lost count of the number of times I’ve seen Anaplan’s generic “versions” applied to a module that didn’t need it. Because it is so foundational to Anaplan’s functionality, newer model builders tend to overestimate its relevance and apply it to modules unnecessarily. However, by explicitly detailing the context of the versioning to your model builders, with custom versioning lists, you make your model more transparent and reduce the likelihood of this mistake. A model builder is more likely to unnecessarily apply the generic “versions” to a module versus a list titled “top-down target versions.” And by not having versioning applied to modules that don’t need it, you’ll make your model simpler and smaller in size.
Costs of using custom versioning lists. When you leverage custom versioning lists, you are still able to “bulk copy” across the list members within them, and you do so through the standard versions menu. However, any switchover logic you were intending you’ll have to build in manually. Additionally, you lose the ability to leverage Anaplan’s built-in version formulas, such as “ISCURRENTVERSION” or “PREVIOUSVERSION.” In general, these inconveniences are minor relative to the benefits of using custom versioning lists.
4. Build a scoping matrix
The Anaplan scoping matrix is a long-term planning framework that will help you manage your Anaplan deployment as it grows. The process of creating a scoping matrix is simple. List all of your Anaplan models in a matrix with Anaplan’s key features listed across the top. Then fill in any intersections where you are using that particular feature within that model. Below is a dummy example. Note that the Anaplan features you decide to track will vary between customers and use cases.
Building and maintaining a scoping matrix will provide a number of benefits to your organization:
Driving simplicity. Every Anaplan feature you leverage represents additional cost of ownership, in terms of both ramp and maintenance. If you see a feature that is not critical or was put in for test purposes, you should consider removing it to simplify your deployment and reduce your overall cost of ownership.
Building expertise. On the other hand, if you have a feature that is critical to deployment (for example, custom versioning lists), consider leveraging it in more than one use case to build up expertise among model builders.
Platform updates. As new Anaplan features are released, test and get feedback from your builders and users. Use the scoping matrix to assess their benefits and periodically re-evaluate which features you want to maintain.
Model handoffs. Whenever you need to hand off a use case to a team member, the scoping matrix provides that person insight in terms of the expected workload and any ramp areas they may need to invest in.
Most Solution Managers will agree that simpler models are more sustainable. An active approach is required to encourage model simplicity. The Anaplan scoping matrix is a great tool to help you drive towards that simplicity.
5. Import action maintenance
Poor import action maintenance is one of the biggest issues affecting model sustainability. We know we should take an active approach in managing and updating our Anaplan actions. Any tenured model runs the risk of eventually looking like the example on the left rather than the cleaned-up example on the right.
There are a few reasons why models end up having trouble with managing import actions:
Autosave of all imports. Anaplan saves every import action you perform, even if it’s a one-time CSV upload. Over time, after several model updates and builder handoffs, the import action list can get messy if it’s not maintained.
Lack of a standard naming convention. You’re about to import into a list — do you prefix the action with “LIST BUILD,” “LIST APPEND,” or “LIST CREATE”? The fact that a platform-wide standard doesn’t exist can make it difficult to enforce a consistent rule set, even among your own model builders.
Cleanup process. Deleting actions can be an intimidating process for less experienced model builders. Deleting an action could potentially break things in your model, but leaving an action in can’t directly break anything, so the tendency is to err on the side of caution and leave more actions around than needed.
Import action maintenance is probably one of the least enjoyable processes of managing an Anaplan deployment, but maintaining a rigid discipline around import actions is easier than working on a model with its action list in disrepair. Below are a handful of tips that can help you:
Required process mapping. Set a rule with model builders that all repeatable actions must be mapped to a process. Mapping an action to a process is good for organization and prevents the action from being deleted.
Regular action cleanup. Whether it’s a daily scrum or a weekly PMO, make sure you have action cleanup on your team’s agenda. If your entire team is aligned on making this a priority, you have a greater chance of success.
Create a pending deletion section. If you create a pending deletion section at the bottom of your import action list, any ad hoc import will show up there. It’s a simple way to queue your action cleanup discussions.
Use a defined naming convention. Naming conventions will vary between companies, use cases, and implementation vendors. Make sure you establish one and communicate it with model builders. Below are examples of the prefixes I’ve used:
LIST APPEND: intended to add additional items to a list.
LIST HIERARCHY: intended to update the parent value for list items.
LIST SUBSET: intended to update whether or not list items are included in a subset.
MOD DATA: general category for any import with the primary intent of feeding data into a module.
INPUT RESET: any import intended to reset an input value to either zero, blank, or other default value.
Making your Anaplan deployment more sustainable may seem like a steep hill to climb, especially if you have a complex use case, with a long tenure and the input of several different model builders. But for those of us who’ve used the platform for a long time, we know sustainability is a requirement for Anaplan to achieve its full value proposition. Your Anaplan model should be making your life easier and simpler, and it shouldn’t feel like you’re dealing with the same problems every year. It takes hard work, discipline, and ultimately a few iterations to get things moving in the right direction. By focusing on sustainability early and often, you’ll cultivate a better Anaplan experience for model builders and end users.
What best practices would you add to this list? Leave a comment!
About the author: Matthew Kuo
Matthew Kuo is a Master Anaplanner who has used Anaplan for nine years. He has spent the majority of his Anaplan career working in the high-tech industry working on sales operations, finance, marketing, and HR use cases.
... View more
First off, I want to say that I definitely appreciated the L3 training and it was very different than any prior Anaplan training I had taken. This one really did feel more like a real implementation, and put you in situations that model builders actually face. While much of it was review for me, I definitely learned a few things and gained some refinements to my approach. (I had no idea you could import the "No Data" format into other line items that were formatted differently) The training took me around 25 - 30 hours total. While I was able to schedule out lengthy blocks of time to work on it initially, I had to wrap the training up in very small increments because of our Annual Planning Cycle. Tips for Future L3 Students Take the test in as short a period and in as few sittings as possible. I don't think it's a spoiler to say that the L3 training involves a moderately complex build. And if you try to complete it over a long period of time, you'll likely forget assumptions you made, where you put those assumptions, how you organized your model, how things were labeled, etc. During the build, tag your modules with the User Story you happen to be working on, either in the Module Name or Notes. As someone who did have to jump in and out of the training at least a few times, I found this extremely helpful in terms of re-orienting myself. Use a Highlighter. Most Microsoft applications have a "Draw" menu with a highlighter as an option. This is useful for dealing with text heavy User Stories, helping you both call out and retain the most important elements. Create and use a Restore Point Module. This is a simple module that allows you to create reference points in your model change history, right before making a big model change (usually imports, or any actions that affect lists). That way, if the change you push through ends up breaking things, it's very easy to restore to the exact point before the change. I never had to restore my model during the training, but having / using this definitely made me more comfortable during the build. Suggestions Importance of getting the actual data - I know it's a training and will never be a complete reflection of reality. But I just feel it's worth calling out how important it is to get the real data for the project. (Even though this particular aspect doesn't have any consequence in the training itself) In my experience, I find the situation of - "You collect user stories and the data represents exactly what the customer said" - almost never happens. And if you wait too long to get the data, any work you've put into building schemas, drafting mockups, or even actual model build would potentially need to be redone. High Level Data Flow Map - While I felt that the sections covering the creation of mock-ups and building of detailed schemas were useful, one thing that was not included and that I've done much more often lately is - build a simple High Level Data Flow. (cleansed example below) Intended to be simple and one-slide only Does not require a technical / Anaplan background to understand Therefore, gets socialized and receives feedback from a wider audience during the project Much easier and more worthwhile to update "during" the actual deployment than the detailed schema Much easier to convey Anaplan's value proposition during project read-outs Ambiguities - During the L3 training, I definitely noticed what I'll call "ambiguities" during both the build and the exam. I won't go into detail here, but I've sent a message to the Academy Team regarding the issues I noticed. It's possible that some or all of these were intentional, but I can definitely see these issues tripping people up during the course. Support Options - On the point of getting tripped up, while I fully respect the desire for people taking this training to handle things on their own, if someone does get stuck on an exercise or other part of the training, they really have no other recourse but to redo significant portions of the training. This could easily mean several hours of rework. I just wish for these situations, people had more support options, as I know for many people, finding enough time to do the training just once is very difficult. Two suggestions I have are: Additional "Check Your Build" snapshots - maybe only show them for those who don't pass the exam on their first try Dedicated support email for L3 questions - where people can ask questions when they get stuck, and the owner of the email is trained to provide hints but not give full blown answers (big ask I know, but would be really helpful) Again, would like to reiterate that (despite my myriad comments) I thought this training did a really good job of simulating an actual build, and it forced you to think like someone who was owning a new Anaplan build. I know these trainings are not easy to design and the significant amount of work you folks put into this was very apparent. Thank you for hearing me out. Best, Matthew Kuo
... View more
@DavidSmith thank you for putting up with all my annoying feature requests. 😉 I've always deeply appreciated and am still motivated by everything you've done for this platform. Truly wish you all the best on your future endeavors! Matthew
... View more
An import action section can quickly become disorganized, making ongoing management challenging. Learn why this happens and explore steps to take to prevent this from occurring.
Import action section: why does it become disorganized?
Anaplan saves every import action that you perform, no matter what. For a new build, the entire model structure and design can change completely by the end of the project. For many deployments, you don’t know which imports you want to save, until you are much further along in the build.
Cleanup rules are hard to enforce if you have multiple users. With multiple builders, you are discouraged from deleting imports from other people, as you don’t want to interrupt their work.
Import action cleanup is generally saved for the very end of the deployment. Team members run into a time crunch, and when weighing other priorities, simply don’t invest the time to clean up this section. If you take no steps to codify your import actions during the build, delineating your “Final” imports from “Test” imports at the end can be an extremely difficult process.
Without proper guidance, deleting imports is a very intimidating process. Everyone knows that if you delete the wrong imports it can completely break your model; therefore, it’s always easier to just leave the import section unmaintained.
Below is an example that shows the difference between a well-maintained import section list and one that is not:
Additionally, below is an example of a model where not all sources are tied to actions. Tying all of your import sources to actions is another step to take to ensure that your model automation settings are as clean and transparent as possible.
Effect on process auditing and model longevity
The effect of an improved naming convention for imports is most evident in the model handoff process and, consequently, overall model longevity. It is not uncommon for Anaplan processes to be handed off to people who were not involved in the initial build. If you simply leverage the default naming convention for import actions, the ramp-up process is much more difficult. Using a customized naming convention makes it significantly easier for a new user to decipher what the model is doing and to audit the process if there is a problem.
Categories to create
LIST APPEND—intended to add additional items to a list.
LIST HIERARCHY—intended to update the parent value for list items.
LIST APPEND & HIERARCHY—intended to add additional items to a list and update the parent value for list items.
LIST SUBSET—intended to update whether or not list items are included in a subset.
Additional thoughts on List Imports:
All list imports are structurally the same and can perform updates to every listed category all at once (append, hierarchy update, subset update).
You should purposely separate these as different import actions to make your model easier to understand and more transparent to other users.
LIST ATTRIBUTES—as it is now best practice NOT to use List Properties, we now create LIST ATTRIBUTE modules that represent the same function.
These are simple modules, dimensioned only by the list in question with line items in place of list properties.
Put it right after the list import section to hopefully make it less confusing.
MOD DATA—general category for any import with the primary intent of feeding data into a module.
The example shown is from a simple deployment, where only one category was necessary; how complex you need to make this section will vary significantly based on the nature of your deployment.
Consider creating your naming convention based on either dimensionality, versions, or time (ie MOD DATA DISTRICT SEGMENT, MOD DATA CURRENT, MOD DATA HISTORICAL, etc.).
INPUT RESET—any import intended to reset an input value to either zero, blank, or other default value.
Separators and category labels
The separators and category labels are simply empty lists being imported into other empty lists; this minimizes the text footprint of these artifacts. To create a new separator or category label, simply select an existing divider, select import, and choose a separate existing divider as the import source.
If any of these import actions run by accident, nothing destructive will happen to your model. The names of the dividers look the same, but the number of spaces between the periods is different for each separator. Note that the divider and section label names need to different than any names you are using for any list or module names. Remember to add an “Imports Pending Review for Deletion” section at the very end—all new imports will show up under this header initially.
Enforce business rules to promote better import management
Use a defined naming convention for all imports that you intend to repeat
If you don’t have one, just start with the base example shown previously
All repeatable actions must be mapped to a process
Actions cannot be deleted without being removed from associated processes; this encourages you to perform your due diligence before removing an action.
All actions not mapped to a process are pending deletion
In the middle of a build, if you are crunched for time or a formal import naming convention has not been set, use an asterisk (*) to tag imports that you intend to save.
All actions intended to be saved must have a descriptor in the notes section
During a deployment, add import action cleanup as an agenda item on a weekly review
For a live model, the import action review period will vary depending on the amount of change that occurs, but consider a quarterly review at a minimum.
... View more
I see, so the export "acts" like creating a new saved view. So when you want to change one of the foundational parameters of the "Export Saved View" (ie add an additional filter, show columns that were originally hidden, re-pivot the module), is the only option to recreate the export?
... View more
Sorry, couldn't find a official answer to this, and I've had different interpretations on how this worked over time, but just wanted a definitive answer: For export actions that you intend to repeat, what is the "official" way that the Export action is defined, relative to the module you are exporting from? We all know that import actions can be mapped to saved views, and any time that saved view is changed, the import action updates along with it. Need to add a line item or update a filter related to an import? Just do that and update the saved view, and you're good. The saved view is a good reference point / validation check for what will actually pass through. As I understand it, that is NOT the case with Exports. With that in mind, just wanted clarification on what "exactly" an export action maps to? Is it: the default module view? the module filter/line items shown, at the time of your export? and if the former, how do you designate whether new line items appear in the export action? (I assume it's to use the "show" command one your line items, to prevent new line items from appearing, but I've had some weirdness in these scenarios and wanted to confirm) I've generally had to lock down export definitions tightly, due to dependent source systems. But getting more cases where people want to append line items to pre-defined, repeating exports. Thanks!
... View more
The import action management section often becomes messy because ALL import actions are saved. Would love the ability to create sections and separators, to better organize the import actions I intend to repeat. The following example was created from dummy imports, but it would be great if this feature were built in. I think the specific categories should be customizable by the user, but the ones I currently use are: List Append Imports List Hierarchy Imports List Subset Imports List Attribute Imports Module Data Imports Input Reset Imports
... View more
As the Anaplan App Hub is currently undergoing a redesign and upgrade, this post will serve as the formal documentation source for the Anaplan Foundation Model. Anaplan Foundation Model Download Process: 1. Click on the link below to begin the download https://sdp.anaplan.com/launchpad/nonpublic/AppInstallWorkspaceRedirect.action?appstoreAppGuid=8a81b... 2. Select your Customer / Tenant 3. Select your Workspace 4. Model will save with the following name: Anaplan Foundation Model v1.0 Documentation attached: Anaplan Foundation Model v1.0 AFM - User Access Template v1.0
... View more
I created a documentation link for an App I recently released on a forum post. Link below:
When I updated the post with the download link for the app, the system marked my post as spam. Is there anyone that can fix this?
... View more
As the Anaplan App Hub is currently undergoing a redesign and upgrade, this post will serve as the formal documentation source for the Anaplan Foundation Model.
Anaplan Foundation Model Download Process:
1. Click on the link below to begin the download
(Old Link) https://us1a.app.anaplan.com/launchpad/nonpublic/AppInstallWorkspaceRedirect.action?appstoreAppGuid=8a81b013706ef3460170ee8b26af391b&_ga=2.171667814.757164856.1588269641-1243030014.1581562170
2. Select your Customer / Tenant
3. Select your Workspace
4. Model will save with the following name: Anaplan Foundation Model v1.0
Anaplan Foundation Model v1.0
AFM - User Access Template v1.0
... View more
https://www.linkedin.com/pulse/five-things-every-anaplan-solution-manager-should-maintain-kuo First off, thank you to everyone who's liked, shared, or commented on the article I posted on LinkedIn last week. (and sorry if I missed anyone) You guys are my #anafam. @ChrisWeiss @andrewtye @Beauram @jdolich @Aaron.wasinger @YelenaKibasova To get a little personal here, I wrote this article during a pretty dark period of my career and just recently got around to posting it. For those of you that have also made the transition from consulting to industry, you understand that, as the "Anaplan guy/gal" at a company, the workload and pacing can be very imbalanced. Once the latest deployment has wrapped up, it's difficult to not, at least on occasion, question your own value to the firm. This is further reinforced by the fact that, most job postings for Anaplan work still have the title of "Senior Analyst" or "Data Architect". The actual role of "Anaplan Solution Manager" doesn't truly exist yet. But, for Anaplan to achieve its market share and growth goals, this role needs to exist. Therefore, I felt the best way to help with the situation was to: Write an article as if the role already exists Provide better detail and definition around what the role entails I'm hoping you all can read, comment on, and promote the article to your networks - my primary goal is that those of us who have dedicated Anaplan roles will have better and more career opportunities in the future. A Challenge to All Anaplan Partners: Create Anaplan Footprint Maps for your Customers Free of Charge I have no idea how many of you are already doing this, or how many of your customers already have Footprint Maps, but the one thing I know for certain is that there are several existing Anaplan customers who have not yet reached this level of sophistication. Creating the Footprint Map at Tableau was a fairly quick process that only took about 3 hours of my time. Most of that time was spent just wrangling people from different departments to get specific details about their deployment. I highly encourage you to read through the article's first section about Footprint Maps, particularly the "tough questions." I really have no idea how you could possibly have a strategic discussion about Anaplan at a company without some type of a Footprint Map in place. Building the Footprint Map is not a time intensive process and it will go a long way in terms of establishing yourselves as the "trusted advisor" of your client on all matters related to Anaplan.
... View more
Saved Views are a critical feature for most Anaplan models. The key issue I have with using and managing Saved Views is that, they can vary drastically in terms of importance. Below are two examples of Saved Views: A Saved View could represent a key, filtered definition within a module that dictates how your entire organizational hierarchy is built A Saved View could also be a quick personal summary that "Bob" from Accounting built, simply because he wanted to see his columns at 50 pixel width I truly wish Anaplan had more options around tagging and organizing Saved Views, to indicate their relative importance. Right now, we use a simple system of "starring" saved views to tag them, in an attempt to indicate their usage and importance. Ask 1: Make saved views more prominent in general, more easily accessible, and easier to manage and organize. Functional Areas and the New UX definitely do a better job of making Saved Views more prominent, but I feel it can go further with: - Sorting Options (I know you can move them up and down, I just wish the interface was a little smoother) - Usage Details - Priority Segmentation Ask 2: Auto-tag options for saved views based on their usage - If I link a saved view to an action/process - please note it automatically. That way, I know not to delete it and also know to check it very carefully if I ever need to change its definition. Ask 3: Give us a way to manually tag saved views, to indicate its importance. In theory, an Anaplan export "leaves" the Anaplan ecosystem, but there could still be critical processes built on top of that definition that just happen to sit outside the Anaplan platform. (ie a Tableau Viz that expects the Export to look a particular way)
... View more
As a quick reminder, we have our Seattle User Group coming up on March 19th, at the Tableau offices here in Fremont. Registration link below: https://usergroups.anaplan.com/events/details/anaplan-seattle-presents-pac-nw-user-group/#/ @Aaron.wasinger @eschera All attendees get early access to the Anaplan app I'm working on. Attached is a sneak preview image.
... View more
Just wondering if / when the App Hub will be available again, for new App submissions. I'm hoping to "release" an app for the next Seattle User group, but without the App Hub available, that will be really difficult. I can reach out to support to do manual workspace transfers, but with 15 different customers, the process would obviously be cumbersome.
I've sent a number of emails to people associated with the App Hub, submitted a couple inquiries through the App Hub submission form, and have not yet received a response.
App Hub Website
... View more
One of our best Anaplanners at Tableau recently left the Sales Operations organization. She unfortunately will not be an Anaplan user in her new role. Before she left, I made this "best practice" image for her, referencing an incident 2 years ago, when I was only 2 months on the job here. Joking aside, I've recently been doing the new L2 training, and in going through that process, I got flashbacks of my early days with Anaplan. I remembered how deflating it was any time I messed up a formula, toasting the model for everyone. There's no doubt in mind that this has a tangible effect on new user enablement, especially if it's a brand new Anaplanner ramping up onto an established Anaplan model. I know the Development Team is already working on features to preempt the need for Toaster Time processing. (ie tell you it's going to toast before it tries to process your formula through the rest of the model) But in the meantime, it would be great if we could just have the option to NOT shame the toaster. Just a simple boolean option somewhere in the settings. It's an easy way to be "nicer" to the newer Anaplanners. If Anaplan is ever going to reach massive appeal and attain its market share goals, we'll need to treat these people better and make the enablement process as easy as possible. Some suggestions for the new "Toast" messaging:
... View more
Big thank you to all the Master Anaplanners I interact with on this board, even if you don't laugh at my corny jokes.
@Jared Dolich @usman.zia @andrewtye @Tiffany.Rice @Ameneh @Beauram (and anyone else I might have forgotten)
At work, I have to fill the role of Anaplan evangelist, which can sometimes can tiring and difficult. I always know I can come back to this community to restore my energy and reaffirm my passion and commitment to this platform.
Also, big thanks to @ChrisMullen for putting up with my complaining and getting those L2 training updates in so fast.
... View more
For all Anaplanners that live in the Seattle / Portland area, I created a LinkedIn Group for Anaplan job opportunities. URL link and background below: https://www.linkedin.com/groups/13831116/ Recently, one of my close colleagues, Aaron Wasinger, a Customer Success Business Partner from Anaplan, informed me that one of his other customers was looking for an experienced Anaplan resource. I realized that, despite having used Anaplan for more than 6 years, I didn’t really have any contacts to provide. When I worked in consulting, people developed expertise quickly and the turnover rate was very high. Back then, it would have been very easy for me to drop several names. Now that I work in industry, that context has definitely changed. The background and purpose of this group is as follows: 1. Anaplan is now a well-established platform with growing demand, and several companies that require expertise 2. Being proficient in Anaplan should provide you some level of job security 3. Networking with other Anaplanners in the area will help you maximize your career potential as an experienced user of the platform Please feel free to post any local job opportunities that require Anaplan experience. This is basically the Anaplan Seattle User Group, except we can be more open about our Anaplan job opportunities, business needs, and career interests.
... View more
Taking the on-demand L2 course right now. There's a slide that says: "Actions involving numbered lists CANNOT be placed in a Process" Pretty sure it was in the Create a Process with Multiple Imports section: Anyway, either that statement is incorrect, or I must be interpreting this differently. I just tested an "Process" action with an import involving a numbered list and it worked fine. (just making sure the functionality hadn't changed on me) I guess the other factor is, we run processes involving numbered lists all the time in our models, so I don't think this can be true, at least the way I'm interpreting it. Please let me know if this actually means something else. If it does, the wording should probably be changed in the training. Thanks!
... View more
In the Actions menu, all processes and actions has a text based "Notes" section. Being very upfront, I honestly didn't even know this section existed until about a few months ago, but I definitely think it can be further leveraged. It would be great if these notes could appear every time, next to your action, before you hit the "Run" button. I've always felt that just naming the action was often insufficient for giving the end user full context - this additional detail could help with that. It's also a good error prevention factor - a user could read the full context of the action and decide not to run the action after being given that information.
... View more
Absolutely agree. It's always a pain to have to clean up your import actions after a long build. There are always a ton of imports in there that are test, or just imports I never intend to repeat. What would be great if we had a save boolean before every import (just like we already have for exports) so we could decide whether or not we wanted to actually save an import in the action list.
... View more
Yeah, thanks Tiffany. I searched for this initially before posting and didn't find anything. After posting, it showed a couple other folks asking for the same thing. Hopefully this will get some traction. 😉
... View more
Would be great to have the option to sort the User List in Anaplan. We have multiple models in the same workspace, and therefore, each model has a long list of users who aren't relevant - they are assigned the "No Access" role designation. Would be great to be able to visually manage this in Anaplan, rather than have to rely on exports and imports, which in my experience, has been inconsistent when trying to update hierarchy level access.
... View more
Absolutely agree. For large complex models, the model map really has no functional purpose because it can't even be understood. All it does is "blue-box" everyone for 10 minutes, when someone accidentally clicks on it.
... View more
This is a quick one, but I was wondering if we could move the Refresh button out of the Edit Menu and into the main module blueprint toolbar? When I explain it to new folks, they always find it un-intuitive to have to open the Edit Menu, before they can Refresh.
... View more
I'm sure this has been touched upon, but couldn't find a post that addressed this directly. Anyway, would love it if the dashboard text boxes aligned automatically. It's annoying how difficult it is to do this manually. Another option is that it would be great if you could click on a text box, and select exactly how many pixels tall and wide you want it to be.
... View more