Accordint to this blog one can hide the business process flows. I'm trying to follow it but there's no flows defined for my opportunity (according to the list).
I'd like to "delete" the flow for Opportunity entity (or at least affect it somehow to display different steps/different number of steps). The reason is that we'll be migrating from an older version and they've got a picklist with percentages of the deal being done. Not sure how to map it onto the Opportunity in 2013 and even if, I'm not sure the client'd like it.
Is it at all possible to remove business process flow from Opportunity in CRM 2013?
When I do follow the guide and fool around with all flows, I get to remove the one for Opportunity but then I'm shown the error message as in the image below. So I'm assuming that it's not the correct approach. Or did the blogger referred to in the first paragraph cheat and took his screenshot after closing the warning? :)
The blogger in the blog is using the earlier version of Dynamics CRM than yours. Newer versions of Dynamics CRM will show the above warning.
Beside one way in the blog, there are a couple of way to show/hide Business Process Flow:
use Javascript to set the display attribute of process bar element:
function hideBusinessProcessFlow()
{
document.getElementById('header_process_d').style.display = "none";
}
function showBusinessProcessFlow()
{
document.getElementById('header_process_d').style.display = "block";
}
Reference: https://community.dynamics.com/crm/b/misscrm360exploration/archive/2014/07/24/show-and-hide-business-process-flow-in-crm-2011-2013.aspx
Please note that this is unsupported customization.
Update processid and stageid fields of the record. Use update these fields with Javascript or writing a plugin/workflow to do this.
Have a look at this solution: http://code.msdn.microsoft.com/Change-Dynamics-CRM-2013-a6beb85e
In your case, you just need to update processid and stageid fields to null, then the annoying warning will disappear.
Good luck!
Are you looking at the complete list of Processes under Customisations? If you're looking at an unmanaged solution it won't appear unless it's been added to that solution. It's in there OOB and called Opportunity Sales Process, I just deactivated it on a clean org. No need to delete it, just deactivate it or edit as required.
There are two things that can be done for any business process flow in MS CRM:
Deactivate BPF
Delete BPF
In order to remove Business Process Flow (BPF) from existing records, it is not enough to just deactivate BPF. Even when we deactivate BPF, records that are associated with it will still show BPF with warning message that it is deactivated.
It is true, if you delete BPF from Processes in MS Dynamics CRM, they will be removed (not showed) from the records that were associated with that BPF. However, what if you do not want to delete default BPFs, like those related to sales process on system entities (Leads, Opportunities and Accounts)? What if you want to hide these default system BPF from default system entity (i.e. Opportunity)?
In this case you need to write plugin/workflow activity to remove association of the entity record from BPF.
See my GitHub example how to do this
This MS CRM community post is also useful:
Remove business Process Flow from Account
Related
Is there a way i can find out if the current meeting window from which i opened the add-in (compose mode) is from a new meeting or from an already created meeting that i opened for edit?
Currently this feature, you requested, is not a part of the product. We track Outlook add-in feature requests on our user-voice page. Please add your request there. Feature requests on user-voice are considered when we go through our planning process.
There are a lot of use cases where this is relevant:
I believe the purpose of many add-ins is to augment the item (e.g. appointment/meeting or email), the user is currently reading or composing. This is usually done in a 3rd party system by associating the meeting in Exchange with a "record" in a separate system. To find out if the current meeting is already associated with a "record" (and possibly display the contents of it), you need a way to identify the meeting obviously. If it's a new meeting, you know there isn't a "record", however if it's an existing meeting, you need to be able to identity it. Exposing itemId in compose mode would satisfy this need. And by the way, the feature is already requested on User Voice!
I can only speculate as to why Microsoft haven't added the feature yet, but I think Office JS started out with support for emails. Compose-mode for emails is almost exclusively for authoring new (unsent) emails, hence they would never have an itemId.
This is not the case for appointments and meetings, however. They are frequently being edited after they have been created, as meetings are often rescheduled, augmented with a more detailed agenda, etc.
Unfortunately the workaround of using saveAsync to obtain the itemId has several drawbacks as you already alluded to: it's very intrusive as it will leave behind "ghost" meetings (as the user now can't regret saving an appointment/meeting) and it causes the sending of spurious meeting update requests to attendees, etc. And it doesn't work in Outlook for Mac! - one of the big selling points of this add-in technology compared to VSTO/COM-add-ins.
At my company we have attempted several times to port our existing VSTO add-in to Office JS, but everytime we stall on this exact issue, as the drawbacks are simply to many!
However, an approach - besides maybe using some crude heuristics - we have thought about, goes like this:
1) Via EWS (or MS Graph), augment every meeting(!) of every user(!) with a custom add-in property containing the itemId. See: https://stackoverflow.com/a/43140644/10752973 on how to set custom properties from the "outside".
2) When the add-in is opened, see if the custom property is present. If the custom property is there, it's an existing appointment/meeting (and you'll know its itemId). If it isn't there, it's a new appointment.
As I said, we haven't implemented it, but in theory it might work. But it's such a huge hassle (and will burden both the Exchange server and the application itself), for something so simple. We would effectively also need to monitor each mailbox in Exchange to detect newly creating appointment/meetings in order to augment them with the custom property, which is needlessly complex.
But I hope this answer might convince the Outlook Add-ins Team to reconsider adding support for obtaining itemId in compose-mode for appointments/meetings.
I'm using an on-premise installation of Microsoft Dynamics CRM 2013.
I have an issue about the Cases section.
The Case entity allows users to track issues and work on them through resolution BUT when a user closes a case she cannot see those “resolution” activities in the Accounts activities list.
Can you suggest a solution for this?
The default activities shows a filtered view of Open Activities. If you wanna find your "resolution" activities, you could use the "Closed Activities" view, or, you can always use an advanced find to filter activities whose Activity Type is Case Resolution and Status is Closed, with, optionally, the Regarding being your case, for example.
If what you really want is knowing how a case was resolved, might be good looking at the "Find resolution to similar cases" section here to link resolutions to other cases.
Cheers from DynamicsValue
I've got a lookup field on Account entity called something. Each such Something has a reference to an account. When my users click the magnifying glass, I want them to see a list of available Something records but filtered to view only such instances that link to the currently treated entity.
Also, I'll need to design such a filtration for Contact instances to only show the Something records that are related to the account that the currently regarded contact is a member of.
I can't decide between a plugin on Retrieve and some JS in OnLoad registering a fetchXML. All such operations will be done client-side. The solution needs only to work in CRM13 (and if possible apply some cool functionality in that version).
Suggestions?
JavaScript & FetchXml are your best option here as with a Retrieve plugin you're taking the performance hit of executing on every retrieve regardless of whether the entity is being retrieved for the lookup. A filtered lookup in JS only applies for those scenarios that require a change to the field on Account.
Another other good reason for using a filtered lookup in Js is they are now a supported feature in CRM 2013 as opposed to the "hack" that was required in 2011.
Some more info on addPreSearch and addCustomFilter can be found on MSDN and there's a decent blog post providing examples here.
I was wondering if anyone could possibly help me with my SharePoint 2010 issue. I recently created a CRM System within SharePoint for my small business which utilizes a email notification workflow. The workflow is triggered when the 'Action Needed' field has a 'yes' value, this means that 2 days after the information is created or edited the workflow will notify the particular user that further action is needed.
Previous thread with image of the workflow
Now this is great if myself or other members of the team are only inputting a couple of items but I found out the hard way when i keyed in 20 or so items and received 20 individual emails which is irritating as you can imagine.
So on to my issue, I would like the email notifications to be grouped together in one email so it's more efficient and avoids the need for individual emails. So when one particular user creates or edits multiple records instead of separate email notifications I would like it all in one email. So is this possible while using SharePoint workflows? If it is possible and how would I go about expanding my current workflow to achieve this?
I have already asked this question in the dedicated SharePoint area to no prevail, I could really do with the help also if what I am asking is impossible then could someone at least say so.
Thanks very much to anyone who contributes and helps me with my problem.
If you are using SharePoint Designer , then this is not problem. This is because each workflow can access the data on which List Item the workflow is triggered.
However, this is definitely possible using a custom workflow or an event Receiver.
http://msdn.microsoft.com/en-us/library/ms437502(v=office.14).aspx
I need to set up different permission on an object based on its workflow state. For instance, 'manager group' can edit the object only if state=draft but 'super manager group' can edit it also if state=validated.
It seems that's not possible using ir.model.access and I'm evaluating if it could be done using ir.rule. It seems not...
Is there a official way to get this or do I need to implement this feature (maybe by adding a condition into ir.model.access machinery).
This is not possible by default with ir.model.access, because this permission model is designed to act like simple Unix permission on CRUD operations, and it is statically defined, per-model and per-group.
You may be able to implement something like this using ir.rule, as it implements dynamic per-record access control based on field values. By having a set of rules defined only on the write and unlink operations and based on the state field, you will be able to prevent some groups from modifying records in certain states. By using the technique of an always-true rule [(1,'=',1)] you can then relax a non-global rule for users who have a "super-access" group. See also this answer.
This option will have important caveats however:
Be careful not to make those rules apply for read, as it will make the records completely disappear, and generally wreak havoc in your processes
The interface will not become read-only when the rule is in effect, and if you want to make the fields and buttons read-only you will have to find a way to specify this via attrs in a manner that depends on the user's groups. See also this Launchpad question.
the Save button in the UI will not be disabled
The standard error reporting in case of ir.rule restriction is not very clear, so it will certainly confuse users (note: it's being improved for 7.0)
As you see, using ir.rule filters for this purpose is far from a perfect solution, and you will first need to find appropriate solutions for the above issues.
Ultimately, you might have an easier task of implementing your own logic for this, plugging a new mechanism in the ORM primitive API methods: fields_view_get (for making fields dynamically read-only based on the user groups) and the CRUD methods (for actually restricting the operations)
There is another way instead of hacking web-client.
You can always have 2 views for the same Object .
For manager group.
For super manager group.
In manager group you can use attrs = {'readonly': [('state', '!=', 'draft')]}
or any condition as you needed.
And in the same way in super manager group, you can put his condition for fields.
I have this feature working on a production environment, using just Record Rules: in Project Issues, "basic users" can create and cancel issues, but can't open or close them.
Despite the GUI limitations mentioned by #odony, it works perfectly.
These are the Record Rules used::
There is a special case that needs attention: changing from a read-write State to a read-only State:
In the action's method, if the the State is changed after other write operations, the user will be able to change the State; but if there are some write operations after the State update, the user will not be able to change State.
In my example, the Project Issue method to Open an issue is case_open(). It first changes State and then does additional changes, like settting Open Date, User and Message history. Because of this, basic users can't Open issues. If you want them to be able to do so, case_open() must be overridden so that it changes State after all other write operations are done.
I got a similar requirement...
My requirement was to make a char field(say "test_123") readonly in the sale.order if the user comes under the group "sale user" otherwise editable for the group "Sale Manager".
That is, if the sale order is in draft state then anyone can edit, but it the sale order is confirmed then this field "test_123" is only editable for "Sale Manger"
What I did is I added a functional field (is_group_manager) which returns True if the user comes under the group "sale manager" and the state is not "draft" otherwise false.
Then in the xml view I added the field "test_123" with attribute attrs="{'readonly':[('is_group_manager','=',0)]}"
for example
<field name="is_group_manager" invisible="1"/>
<field name="test_123" attrs="{'readonly':[('is_group_manager','=',0)]}"/>
This will work only in openerp v6.0. Maybe this will be helpful for you. :)